There are a good many sites out there with information pertaining to SQLi attacks. Given last month’s statistics and current trending, I wanted to take a moment to touch on a few sources and statistics specific to cross-site scripting. First and as always, you will have to decide if the information has relevance to your organization and environment. Know your own network. Threat information by itself is as useless as vulnerability reports. Unless you apply the analysis as to what is applicable and of concern, the data is just noise. Together, threat and vulnerability information with organizational priorities provide useful analysis.
Depending upon the applications you utilize, the folks at Veracode have provided some interesting statistics that show prevalence for SQLi. Using the 80/20 rule, this article will focus on Cross-site Scripting (XSS)
XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are three known types of XSS flaws: 1) Stored, 2) Reflected, and 3) DOM based XSS.
· Reflected attacks involve Tricking a user to click on a link, via having them view an email, or having them view another site under attacker control. This could be as benign as a forum where image tags are allowed, and an attacker posts something like <img src=badcode.html/>
· Stored attacks involve Creating an XSS attack and storing it on the target site, such as in a forum post, profile, or other method. This type of attack may also be self-propagating, creating an XSS worm or watering hole.
· DOM-based XSS (or type-0 XSS) attack occurs when client-side scripts (such as JavaScript) manipulate the page's DOM, allowing an attacker to run JavaScript in the victim's browser. This class of XSS is distinct from Reflective XSS (type-1 XSS) and Stored XSS (type-2 XSS), since the server is not returning executable JavaScript to the browser. Instead, data that has been sanitized by the server, or possibly never sent to the server, is converted to executable JavaScript by the existing code running on the page
There are a few ways to prevent XSS with the recommended “keeping untrusted data separate from active browser content” as the gold standard. Details and cheat sheets can be found at: https://www.owasp.org/index.php/Main_Page but testing your own site code is a must. There are a number of tools that do this including a free ZAP scanner https://code.google.com/p/zaproxy/
No comments:
Post a Comment