XSS Continues To Be A Profitable Vector Of Attack

History of Cross Site Scripting Attacks

Since the 1980s when the efforts by Tim Berners-Lee and others resulted in the World Wide Web, we’ve been struggling to take an environment that was not focused on security and make it secure.  In fact, the focus was one of an open platform to be used for sharing.  Controlling proper usage has been like pushing a rock up a hill (or whack-a-mole, the analogies abound).  A couple of examples of our struggles up to now include:

• Samy (also known as JS.Spacehero) was a cross site scripting (XSS) worm that was designed to propagate across the MySpace social-networking site. Within just 20 hours of its October 4, 2005 release, over one million users had run the payload making Samy the fastest spreading virus of all time.
• In 2010 a XSS bug affected Amazon’s allowed attackers to steal the session IDs that are used to grant users access to their accounts after they enter their password. It exposed the credentials of customers who clicked onthis link while logged in to the main Amazon.com page.
• The Indian security researcher Shubham Upadhyay aka Cyb3R_Shubh4M, discovered a XSS flaw back in 2012 that affected the products listings on Ebay.com. It sometimes got executed in another subdomain with an iframe (in Google Chrome), but was also tested successfully on Firefox with the javascript code being executed on the www.ebay.com domain.

“XSS bugs are the most commonly found security vulnerability”

- Jeramiah Grossman, a web application security expert.

To help address application vulnerabilities, The Open Web Application Security Project (OWASP) was founded to provide a repository of knowledge that web developers and operation managers can use to build and test the most robust web applications.  They’ve created a benchmark test available to all to help determine how successful the development and maintenance effort has been.  OWASP helps measure and differentiate the effectiveness of the diverse range of solutions being offered.

Evolution of Tools and Testing to Thwart these Types of Attacks

The rise of static application security testing (SAST), dynamic (DAST) and ultimately interactive application security testing (IAST) were tools designed to be used in the development process of code.  While this is certainly considered part of a best practices suite during code development, what can be done about 3^rd party and legacy code?

Web Application Firewalls (WAFs) came into being to help thwart this problem.  Many organizations have invested in WAF for quite some time. Large portions of the security budget may be devoted to supporting WAF implementations. However, are you finding that WAF is only useful in some – not all – of attack scenarios? There is a reason you are noticing this lag. WAFs provide broad perimeter defenses (generally at the data center level) and mitigate threats at the edge of a network. At face value, this is an attractive value proposition, but the deficiencies of WAF are generally only seen during the post-implementation phase when it comes to operating and maintaining the solution.  Ideally, the solution identifies all of the valid attacks and correctly ignores the false positives.  The Virsec solution ran these tests and scored with ideal detection.

Runtime application self-protection (RASP) is the logical evolution of these methodologies in that they incorporate tools directly into the application allowing them to “self-medicate” in real time.  RASP is more focused on the business logic and doesn’t easily address legacy and 3^rd party applications that challenge the integration of these tools.  While RASP may address WAF deficiencies, they can have the wrong effect if the result of finding an issue is to halt the process.  Many business-critical systems cannot afford any service interruptions (see industrial control systems).

Keep Your Enemies Closer

While probably attributed to Michael Corleone (Godfather, Pt II), the idea of keeping your friends close and your enemies closer may go back to Sun Tzu.  It applies in this context in terms of identifying what may be causing you harm.  Applications have a deterministic way of executing when loaded into memory.  Any divergence indicates some abnormality that needs to be identified and mitigated.  By mapping the valid content and format of a URL, incorrect activity can be monitored and prevented at the microsecond level. Rather than attempting to monitor from the network or use heuristics why not focus on understanding the known good.  A form of whitelisting at a more granular level, mapping the route the interpreted code was designed to take and ensuring that any aberration from that path is detected immediately.  Map the correct behavior such that it becomes deterministic.  One right way.  Any derivation is detected, alerted and/or prevented (this last piece being custom enough to fit a customer’s current best practices via an API).

The latest incident of this ongoing problem (XSS flaw found in the Google's PHP API enables phishing attacks) just reinforces the argument that the current solutions need a fresh approach.

Goals of approach:

1. No false positives
   • Too much time is spent chasing after perceived problems. A solution that works at the application level and doesn’t rely on signatures, statistics or heuristics have a higher degree of accuracy due to its proximity to the attack.
2. Easy instrumentation
   • Lightweight probe (read only) resides on the application server and communicates with a remote (on site or cloud) analysis engine; minimal overhead/impact on server providing the business value
3. Contents examined and mapped dynamically
   • Mapping guarantees correct execution every time. As rules are deterministic, so is the check that validates operation.
4. Broad Web app attack protection
   • New variants exposed on execution as mapping is checked on every transaction.

In summary, XSS attacks continue to be profitable for bad actors.  New variants are created at an alarming rate and current attempts to stay in front of the threats have been unsuccessful.  As the IoT of the web continues to expand, protecting attacks against web servers needs to be a priority.

Virsec Platform takes a radically different approach for detecting advanced attacks on the full application stack (from binaries to business logic) from individual servers (including VMs and Containers) to complex multi-tier applications.

To see Virsec Platform in action, get in touch now.