Mark is presenting a talk on "Maximizing the ROI of Your Pentest" at the ISACA Denver Chapter meeting on April 17, 2025.
Key thoughts are:
- Where does penetration testing fit in a security program as a whole?
- When managing a pentest, what can you do to get the most bang for your buck?
- How can you tell if you got a quality pentest, especially when there aren't a lot of findings?
Download Slides
Technically this should have been organized in the "resources" section. But, in order to be able to just post one link at the end of my presentation, it's here in the blog.
As early as 2010(http://www.thread-safe.com/2015/01/jwt-5-years-in-making-history.html) a new standard for handling session tokens was under development. This standard had the goal of “defin[ing] a compact and self-contained way for securely transmitting information between parties as a JSON object.” The result was a rather simple (not a criticism) standardized method of packaging and cryptographically signing a JSON object. In a nutshell, each JWT has three parts. Each of the three parts is individually encoded using Base64 and then joined into a single string with periods as the separator between parts. The middle part is the payload and contains any arbitrary JSON object. The standard also defines some field names that are recommended for use inside the JSON payload for common use cases, but all are optional and additional fields are welcome. In order to be able to prove who created the token and prevent tampering, the third section is a cryptographic signature of just the payload portion of the JWT. Many signing algorithms are supported so the first lists which algorithm was used to create the signature as well as any additional parameters that the signature may require.
Read more: JWTs - Only Slightly Worse (Browser Defenses Bonus 1)
We’re all familiar with the core security tenet of “defense in depth”. Obviously we want to do everything we can to protect the confidentiality of our session tokens, but there are also valuable things we can do that will help contain the damage if they are eventually compromised. These techniques focus on limiting the window of opportunity during which an attacker can make use of a stolen token and in some cases they can reduce that window to nothing.
Introduction
All of the previous attacks covered in this series are different methods of reading the value of the session token. Once the attacker has that value, they can include it in requests sent from their own system to impersonate the victim and access the targeted website. There is another group of attacks where the attacker never actually obtains the value of the session token, instead they trick the victim's browser into sending a request to the targeted site and rely on behaviors that will automatically include the session token. These attacks typically require that the attacker know the exact request they want to send, which requires more preparation on their part, but the benefit of these attacks is that they skip the need to bypass many of the defenses put in place to keep the session token secret.
Cross-site Scripting has appeared on OWASP's Top 10 Most Critical Web Application Vulnerabilities list since its inception in 2003. The 2021 revisions has it at number three after having been grouped with together with other "Injection" attacks. This grouping makes sense because like other injection attacks, vulnerabilities come from the combination of user controlled input that isn't properly validated and a lack of output encoding when placing that input into a context where it can be mistaken for commands. In the case of Cross-site Scripting, the context is a webpage where the input can be interpreted as either HTML code that runs JavaScript, or in some cases JavaScript code directly. Because of this, a growing number of security professionals prefer the term "JavaScript Injection" to "Cross-site Scripting" since there is no requirement that the attack be "cross-site" at all.
Read more: JavaScript injection a.k.a. Cross-site Scripting (Browser Defenses Part 4)
There’s an oft quoted saying that those who forget the past are doomed to repeat it. The history of the web is full of new technologies, attacks against those technologies, and more technologies to defend against those attacks. From the beginning, there has been an arms race between attackers and defenders and if we forget the first battles of this race, we risk undoing the progress we, as a community, have made. So let’s speed run this arms race, broken down by attack methods, to remind ourselves why some old school defense technologies are still a good idea. This series of articles will focus on a core building block of the web, the session, and the set of defenses available to fight for the user.
Read more: Browser Session Defenses – Everything Old is New Again (Part 1)
|
Recommended Defenses:
|