Your developers are plugging away, churning out code and checking off backlog items. Everything is going great and the project is surprisingly on time. But just when you thought you were approaching the finish line, you get that message from the security team you’ve been dreading:
This week, we ask Automation & Integration Specialist James Hobbs some questions about Application Security Pipelines and achieving Continuous Security in DevOps.
Does your application release cadence leave time for security? For many organizations, the answer is simply – “NO”.
Organizations face challenges when using the traditional “bolt-on” approach to application security. Security teams are unable to keep pace with the demand of application delivery and deployment so that application security becomes a roadblock – expensive and requiring too many resources. Development teams resist security requirements, knowing that it will slow them down.
How can organizations bypass these issues? By using an Application Security Pipeline to achieve their security goals.
Aspect’s engineers have assessed thousands of applications and complex systems – and year after year we find the same design flaws and implementation vulnerabilities. Organizations continue to be breached via the same vulnerabilities that have exposed so many others.
There’s plenty of blame to go around for the problem. But with thousands of vulnerabilities, threats and attack vectors, application developers and security teams face an astoundingly complex problem.
Training helps developers recognize and avoid the most common vulnerabilities; it can help prevent some breaches. But what organizations really need is a framework that facilitates laser-like focus on what matters most in application security – something that cuts through the clutter and gives developers and security teams a clear roadmap to secure the most vulnerable elements of their applications.
Getting developers to care about security is tough. They are inundated with security best practices to implement in their applications. Most of the time, they have a checklist mentality – a list of items to complete. Less often is there a genuine understanding of the desired outcome or the spirit behind each security control.
The result? Production applications comply with company policy, but still contain dangerous vulnerabilities that hackers can exploit.
At Aspect, we think a lot about how to help application architects, developers and security professionals understand – really understand – the root causes of the most serious vulnerabilities used by hackers today. How do we move past rote memorization and checklists?
One of my favorite things to do around Christmas is to participate in SANS Holiday Hack Challenges. These challenges are a fun way to learn and practice hacking skills. They are released once a year around Christmas and cover a broad range of technologies, tools and hacking techniques. Aside from the high quality of the exercises in an extremely gamified environment, these challenges are: 1) absolutely free; 2) available indefinitely, so folks can play year-round, going back to past challenges as they wish.
The 2016 challenge included many tasks such as reverse engineering a mobile application, Linux hacking, password cracking, network dump analysis and, of course, web application hacking. One of the web sites had a vulnerability allowing an attacker to modify their session cookie to escalate privileges from guest to administrator. This was trivial to accomplish after getting possession of the application’s source code along with the hardcoded encryption key. But what if the key was not known?
This article will demonstrate a practical attack on RC4 ciphertext to make controlled changes in the decrypted plaintext without knowing the encryption key. The technique relies on certain properties of stream ciphers.
This page is a collection of instructions to remove unnecessary server headers which may be reported as part of a Penetration Test performed by a security engineer or reported via automated tools. I have cataloged these remediation instructions for many technologies in one place to save the vast amounts of searching required for some of the more obscure technologies.
Each section below is be divided into a short solution and along with a longer one. The “Short Answer” gives the quick means to remove the offending header while the “Long Answer” gives more details along with alternate and (perhaps) more thorough solutions.
Why bother? In general, excessive headers are bad:
- They expose what version of software is running on the server, reducing the work an attacker needs to do before trying to attack the system.
- Headers are the same for a normal user or an attacker. So, a known long string of characters in an encrypted data stream might aid an attacker in cracking open the encrypted TLS connection of another user.
- It’s a general waste of bandwidth and processing power.
As we discussed in Part 1 of this post, Dynamic Application Security Testing (DAST) is often the first step that many organizations take when embracing application security.
Yet we learned that most DAST tools do not provide reliable results without being tuned for the specific application being tested. What does that mean for most organizations?
Dynamic Application Security Testing (DAST) is often the first step that many organizations take when embracing application security.
Dynamic analysis (often referred to as black-box testing) is categorized by testing a running web application (as opposed to static, non-running source code). A DAST tool is usually a scanner that is designed to send malformed and malicious HTTP requests to your application, then interpret the responses and detect potential vulnerabilities.
However, despite how they may be sold, most DAST tools will not provide reliable results without being tuned for the specific application being tested.
A few weeks ago my friend (1) and I attended a hackathon sponsored by a local ISSA chapter (2). The hackathon was a hands-on event where participants learned about common web application vulnerabilities in a fun, gamified environment. The technical platform for this hackathon was provided by Security Innovation (3).
At the end of the event, the two of us finished first and second, with nearly half of the available points each. Security Innovation, however, graciously kept the game open for a few more days to give the participants an opportunity to continue to play and learn.
We used this opportunity to find and exploit more vulnerabilities in the application, and ultimately discover the one that allowed us to completely own the application server.