Podcast: Play in new window | Download
Subscribe: Apple Podcasts | RSS
[headline tag=”div” css_class=”h2″ color=”color2″]Story[/headline]In the chaos that ensued from the Operation Sony, the explicit attack by the hacktivist group Anonymous on the corporation conglomerate Sony, which mainly consisted in DDoS attacks on the Sony Playstation Network (PSN), someone slapped Sony with the homage of “pwned” when they circumvented Sony’s network and made off with over 77 millions user records and possible millions of credit cards. Anonymous claims “for once we didn’t do it”. Eventually, the breach forced Sony to make drastic network changes that required taking the Playstation network offline for 24 days starting on April 20th, Black Wednesday. Was Anonymous responsible for the hack? At least someone wants you to believe they did.
[section_headline tag=”h3″ lined=”yes” color=”color2″]Sources:[/section_headline]
PC World – Former LulzSec Member Gets Prison Sentence for Sony Pictures Hack
Network World – PSN Hack Timeline
Wired.com – Three Anonymous Members Arrest
Krebs on Security – Passwords and Credit Cards at risk
Fortune.com Why Sony didn’t learn from its 2011 Hack
[headline tag=”div” css_class=”h2″ color=”color2″]The Burning Question[/headline]
Question: Many frameworks are now providing native XSS protection, but since most web applications are made up of a number of cogs as opposed to one monolithic framework, what are some general go-to mitigations I should be aware of when it comes to XSS vulnerabilities?
Answer: In a nut shell, cross-site scripting (XSS) is the ability to load a malicious script on your web application through an external source. Therefore the first thing we have to understand is that any external source to our application can potentially be vulnerability of XSS. User input is largely talked about when it comes to external sources, but it can come from any external source such as javascript loaded from a CDN, for example. Using a defense in-depth approach, we can break up our application mitigations into a number of areas in order to help keep our head above water with the number of options, considerations, threat variations and everyone’s 0.2$. A suggestion would be the following categories:
- Application wide – Umbrella mitigations that can cast a wide net on multiple areas.
- Server – Specific mitigations that apply to the server side of your web application.
- Client – Which are mitigations handled by the client (e.g browser).
There are many great articles available to get a grasp on protecting against XSS, such as this one by Troy Hunt, and OWASP, but I also wrote one earlier this year Preventing XSS in ASP.Net made Easy that deep dives it the many areas and contain mitigations that would apply to framework. When it comes to framework agnostic mitigations that we can implement, the following touch points that we discuss in this episode are the following
[list type=”plus” color=”color1″]- Escaping (also known as output encoding) all untrusted data. One major untrusted data is user input.
- Performing input validation for all user input.
- Content Security Policy (CSP) – HTTP header to dictate to the browser what sources it is allowed to acquired resources from.
- Using HTTPOnly cookie flag on cookies through the Set_Cookie header to lock out all sources except the HTTP protocol from accessing your applications cookies. Testing your application. Just as great code is accompanied by great test, so is secure software accompanied by testing its security. There are many testing tools to help you with such HP –
- WebInspect, OWASP Zap. But here you can configure and walk Burp Intruder to test your web application.
These are not a be all, end all list but cover a vast area from a framework agnostic perspective, which is talked about in depth in the previously listed articles. However, a guideline when it comes to understanding XSS vulnerabilities are the following:
[section_headline tag=”h3″ lined=”yes” color=”color2″]General rules[/section_headline]- Understanding how the browser’s role as well as the role of external sources work in tangent and are the key players involved when it comes to understanding XSS.
- External sources and more precisely, any form of user input must be untrusted, assumed malicious and handled properly.
- When applying mitigation techniques such as input validation, leveraging a whitelist approach is the most safest and easiest to maintain. When choosing tools (e.g. AntiXSS library), try to pick ones that also leverage the whitelisting approach.
- Use the Application, Server and client focus area’s to help make mitigations more digestible and more consistent in coverage.
- Understand the different contexts where data can be encoded such as JavaScript, CSS, HTML and URL and utilize a XSS library for applying the appropriate encoding.
- Finally, understand the importance of hacking yourself first and utilizing tools such as XSS scanners to check your work.
[headline tag=”div” css_class=”h2″ color=”color2″]Fabulous Failure[/headline]
Before the at-your-fiinger-tips Apple and Google store, companies had to take other means for certifying approved apps on for their mobile device. Nokia’s choice for their once popular Symbian OS devices, ran into some problems after their highly prized encryption keys were stolen, which ended up in a botch police stakeout and bag of millions of euro’s vanishing off into the night.
[section_headline tag=”h3″ lined=”yes” color=”color2″]Story Sources:[/section_headline]Computer World – Nokie Gives Millions to Blackmailer
Kaspersky Business – The Case of a Money Bag
[Music Credits]
music by audionautix.com