Are you going to the RSA conference coming up on May 17th to 20th? If so, come join us in talks, workshops, and our developer challenge! Here’s what we are up to at RSA and RSA DevOpsConnect.
Look out for a hands-on lab with me and Suchakra, where we will discuss how code can be represented in a graph, which can then be queried interactively to find bugs. We will show you how to use the open-source tool Joern to hunt for vulnerabilities using interactive static analysis: https://www.rsaconference.com/Library/presentation/USA/2021/findings-stranger-things-in-code.
Time: 3:25 PM to 5:00 PM (EDT), May 20th, 2021.
There are many decisions that go into the process of creating a secure website. One of these decisions is selecting which HTTP security headers to implement. HTTP security headers are response headers designed to enhance the security of a site. They instruct browsers on how to behave and prevent them from executing vulnerabilities that would endanger your users.
One of these headers is the Content Security Policy or CSP header. And it’s one of the headers that confused me the most when I was first learning about HTTP security.
The Content-Security-Policy header tells the browser which resources it is allowed…
It seems impossible to write software without using open-source components. A single “import package” can mean thousands of lines of code added to an application. When you look at the software you’ve written, you’ll probably find that 80 to 90 percent of the code is written by someone else.
Since you did not write these open source components, you cannot control how they were written. That means that even if you’ve secured the code that you did write, a vulnerability in an open-source component can easily compromise the application. …
Application security tools get a bad reputation.
Developers often worry that security tools such as static analysis tools would slow them down, make their work look bad, or even cost them their jobs when something goes wrong. But implementing secure practices and using security tools are ultimately necessary for any business that creates software.
What are the barriers that prevent developers from producing secure code? How can we create a security tool that succeeds despite these barriers? What are some considerations when choosing a security tool for a development team?
In this Episode of Sources and Sinks, I host Alok Shukla, VP of Products at ShiftLeft to discuss barriers that developers face when building secure software, and how the team here at ShiftLeft built a security product designed to make secure development easier for developers called ShiftLeft CORE.
I’m excited to say that I have joined Security Podcast Sources and Sinks as their host!
Sources and Sinks is a technology-focused podcast that talks about the business, people, technology, products, the culture of silicon valley — with a security twist. New episodes will be released every month. You can listen to Sources and Sinks on Apple Podcasts, Google Podcasts, Stitcher, Spotify, Amazon Music, IHeart Radio, and many more.
In this new season, we started off by interviewing Saif Bhatti, a rhino conservationist using technology to combat rhino poaching. We also speak to Katie Paxton-Fear, a cybersecurity researcher, to talk…
Last time, I talked about the perils of leaving secrets in open-sourced code and how to detect those secrets using regex and entropy analysis.
Hardcoded secrets are an example of a sensitive data leak. Sensitive data leaks happen when an application exposes sensitive data, such as credentials, secret keys, personal information, or configuration information, to people who shouldn’t have access to that information.
For instance, if an application writes sensitive personal information like customers’ credit card numbers into application logs, that information becomes accessible to system analysts who can read logs. It’s also common for applications to leak users' private…
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 repos or application packages, then into an attacker’s hands. As microservice architectures and API-centric applications become mainstream, developers often need to exchange credentials and other secrets programmatically. This means that developers can sometimes make mistakes when handling sensitive data.
One of the questions I get the most in my Twitter DMs is “How do I write better technical blog posts”?
Technical writing is a specialist skill, and I am by no means an expert. But over the past few years, writing my technical blog has taught me a lot about writing for the Internet. So today, here are my tips to help you produce better technical articles.
Good writing is easy to read. This is especially true when writing on the Internet. On the Internet, your technical blog post has the potential to be shared anywhere in the world…
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!
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.
For example, this DTD declares an external entity named “file” that points to
file:///secrets.txton the local file system. …
Performing a source code review is one of the best ways to find security issues in an application. But how do you do it?
In this tutorial, I will go through some tactics for performing a security code review on your application.
Before you start reviewing code, learn what the most common vulnerabilities are for the target application type. Getting familiar with the indicators and signatures of those vulnerabilities will help you identify similar patterns in source code. For example, the signature for an XXE vulnerability is passing user-supplied XML to a parser without disabling DTDs or external entities. …