Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.
Thankfully, most real-life vulnerabilities share the same root causes. And by studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.
Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.
Thankfully, most real-life vulnerabilities share the same root causes. By studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.
Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.
Thankfully, most real-life vulnerabilities share the same root causes. And by studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.
XSS, or Cross-Site Scripting, is one of the most common vulnerabilities found in applications. In bug bounty programs of different organizations, XSS consistently ranks as the most common vulnerability found. Today, let’s learn how these attacks work, how they manifest in code, and how to prevent them in your programming language. Let’s dive right in!
XSS happens whenever an attacker can execute malicious scripts on a victim’s browser.
Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.
Thankfully, most real-life vulnerabilities share the same root causes. And by studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.
In May 2021, the President released the Executive Order on Improving the Nation's Cybersecurity (Executive Order). The Software Bill of Materials (SBOM) directly impacts all developers. The SBOM requires third-party software companies to provide customers with the code equivalent of a 'nutrition chart.' Looking toward the future, organizations should consider the impact that the Software Bill of Materials will have on software development practices.
Although the Executive Order mentions SBOM in the body of the text, the definition is buried at the end. The SBOM consists of the following:
When it comes to security tools, you're typically balancing two things: how much time it takes for a tool to run to get deeper results vs. the quality of results returned.
As you might expect, faster tools scan just the source code in a single repo (without looking in the open-source libraries and SDK used) and may detect easy-to-find vulnerabilities. In contrast, tools that give better results and can find more challenging vulnerabilities with fewer false positives require more time to complete their scans.
In the wake of several highly publicized supply chain attacks, regulatory and media focus is shifting to address third-party software risk. The Department of Defense’s Cybersecurity Maturity Model Certification, established on January 31st, 2020, was the first attempt at creating a supply chain security compliance mandate. Only a few months later, threat actors infamously gained access to the build environment at SolarWinds and inserted a vulnerability directly into a security update that was then pushed to production. This combination of Insider Threat and Supply Chain Attack wound up compromising customers who installed the update, including US Federal agencies. In response to the growing threat of supply chain attacks, the Executive Order on Improving the Nation’s Cybersecurity established the Software Bill of Materials (SBOM) requirement. Whether for financial or political gain, threat actors are focusing on supply chain attacks. Software developers can prevent supply chain attacks by securing DevOps.
In a supply chain attack, threat actors target a third-party service provider’s cybersecurity weakness, then use the vendor’s product to gain unauthorized access to the companies using the product or service.
Image is sourced from DZone's Twitter
As a developer, I admit that I’ve committed secrets to public Github repositories before. Hardcoded secrets have always been a problem in organizations and are one of the first things I look for during a penetration test. When developers write secrets such as passwords and API keys directly into source code, these secrets can make their way to public repositories or application packages, then into an attacker’s hands.
Welcome back to AppSec simplified! In this tutorial, we are going to talk about how you can prevent XXEs in Java applications. If you are not already familiar with XXEs, please read my previous post first: https://blog.shiftleft.io/intro-to-xxe-vulnerabilities-appsec-simplified-80be40102815.
DTDs are used to define the structure of an XML document. Within DTDs, you can declare “XML entities”. There is a special type of XML entities called “external entities”, which are used to access local or remote content with a URL.
Welcome back to AppSec Simplified! Last time, we talked about the fascinating XXEs vulnerabilities and how they can affect your application. If you are not already familiar with XXEs, please read that post first!
Intro to XXE Vulnerabilities: AppSec Simplified
Wearing a face mask to prevent coronavirus is becoming the norm in my city. It was hit heavily by the COVID crisis, and now we have reached an unspoken consensus: wear masks wherever you go.
This is quite different from where we were just a few months ago. Face masks had a bad reputation, and the local health department had a hard time getting people to wear them. What was stopping people from wearing masks? It turns out, people hated masks because they make breathing difficult, make glasses foggy, and can look quite awkward. But the pros of masks outweigh the cons, and by wearing face masks, we protect ourselves and our communities from the virus.
Most of you know me as an offensive security gal. The fact that I decided to join a SAST team frankly surprised me, as well. Now that I have officially started my job at ShiftLeft, I am taking this moment to reflect on how I got here and how I see the future of application security.
I started my career as a web developer. And I absolutely loved it! I loved building tools that solve someone else’s problems. And there is no feeling like seeing your vision materialize right in front of your eyes.
SAML (Security Assertion Markup Language) is often prone to vulnerabilities as an XML based markup language used to expedite identity checks for bigger applications. This article will go over the usual roadblocks developers might come in contact with when working with the custom SAML solutions, as well as looking into preventative measures for developers to take, stopping vulnerabilities before they happen.
SAML is used for exchanging authentication and authorization data between identity providers and service providers. One of the most common use cases for SAML is facilitating browser-based Single Sign-On (SSO).
Photo by Caozzy Lin on Unsplash
While Regex is wonderful, it can also be difficult to evaluate properly. Poor regex patterns result in mediocre performance incorrect results. But, is it more dangerous than that? Can it also result in vulnerabilities?