- MySQL was compromised by SQL Injection
- Wordpress.com was compromised by an HTML Injection/Cross-Site Request Forgery
- Facebook was hit by a worm exploiting an XSS vulnerability
- Barracuda Networks was compromised by SQL Injection
- Twitter had an HTTP Response Splitting flaw
I believe one of the reason these flaws are still present in new websites is due to the fact that their exploitation and consequences are not fully understood. Here are few misconceptions I have heard.
XSS is simply about popups
- steal user credentials (login, password, session, etc.) and other confidential information (credit card number, mailing address, etc.)
- hijack administrator sessions
- force the download of malicious executables
- run other types of code: Flash, Java, ActiveX, etc.
SQL Injection is not only used to dump a database, or to login without valid user credentials. A lot of web applications, like Wordpress, store the site content into a database. If an attacker get write access to the database, he can insert malicious code which will then be rendered for all users.
Users are at fault for not being diligent
Another belief is that a user must click on link that contains the XSS, CSRF of HTML infection in order to be affected. Since the "bad" content is often shown in the URL the user clicks on, users should simply be more careful.
First, "bad" links can be hidden with a URL shortener, for example and users may not be aware were they will be redirected. Second, all attacks are not necessarily transient. Malicious content can be inserted by one user, or the attacker, and displayed to all other users via a persistent XSS or HTML Injection flaw. It is the responsibility of the webmaster to protect users. This responsibility should not be placed on each user.
A good blacklist will do the trick
|These lines are not interpreted as comments by IE|
|document.write is executed by Internet Explorer|
XSS can hide anywhere
A XSS attack does not require the addition of a new script tag on a page. It can hide in a link, tag attributes, CSS, etc.
|Some examples of encoding|
It's pretty much impossible to get a comprehensive list of dangerous strings. Instead, a tight whitelist of authorized strings and/or characters should be used first, and only supplemented with a blacklist as needed.
I hope that the high-profile attacks that happened recently will push web developers to pay more attention to the code injection vulnerabilities. Many programming frameworks include libraries and functions to take care of most of these issues. Hopefully they will be used everywhere user input is received and displayed. Don't ever trust external input!