Most cyber-attacks happen because vulnerabilities in system or application softw

Question

Most cyber-attacks happen because vulnerabilities in system or application software. Buffer Overflow, SQL Injection, Code/OS Command Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery and Race Conditions are very common vulnerabilities. (Refer to both NIST/DHS and MITRE databases of common vulnerabilities (http://nvd.nist.gov/cwe.cfm; http://cwe.mitre.org/top25/).) For this conference, explain what a specific vulnerability is, describe a famous attack that leveraged it (For example, the Morris worm leveraged the buffer overflow vulnerability), and how it can be prevented/minimized

Explanation / Answer

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Cross-site Scripting is a way of bypassing the SOP concept. Same Origin Policy (SOP) forbids websites to retrieve content from pages with another origin.

Whenever HTML code is generated dynamically, and the user input is not sanitized and is reflected on the page an attacker could insert his own HTML code. The web browser will still show the user's code since it pertains to the website where it is injected.

In such case an attacker can easily insert javascript code which would run under the site's context. By doing so the attacker is able to access other pages on the same domain and can read data like CSRF-Tokens or the set cookies.

If the cookies, which typically contain session identifier information can be read by the javascript, the attacker can use them on his own browser and login to the web application as the victim. If that does not work the attacker can still read private information from the pages, such as read CSRF tokens and make requests on behalf of the user.

Samy Worm

In 2005, Samy Kamkar released the Samy worm, the first self-propagating cross-site scripting worm, onto MySpace. The worm carried a payload that would display the string "but most of all, Samy is my hero" on a victim's profile and cause the victim to unknowingly send a friend request to Kamkar. When a user viewed that profile, they would have the payload planted on their page. 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. The MySpace team temporarily shut down MySpace to fix the problem that allowed the worm to operate.

Prevention

To reduce the chances of your site becoming a victim of an XSS attack, it's essential that any Web application is developed using some form of security development lifecycle (SDL) targetted is to reduce the number of security-related design and coding errors in an application, and reduce the severity of any errors that remain undetected. Vulnerability can be prevented while developing secure applications is by assuming that all data received by the application is from an untrusted source. This applies to any data received by the application -- data, cookies, emails, files or images -- even if the data is from users who have logged into their account and authenticated themselves.

Not trusting user input means validating it for type, length, format and range whenever data passes through a trust boundary, say from a Web form to an application script, and then encoding it prior to redisplay in a dynamic page. In practice, t user-supplied data is reviewed on the site is handled and processed and ensure that, before being passed back to the user, any values accepted from the client side are checked, filtered and encoded.

Client-side validation cannot be relied upon, but user input can be forced down to a minimal alphanumeric set with server-side processing before being used by your Web application in any way. Regular expressions can be used to search and replace user input to ensure it's non-malicious. This cleaning and validation should be performed on all data before passing it on to another process. For example, a phone number field shouldn't accept any punctuation other than parentheses and dashes. Special characters like "<" and ">" should also be encoded before they are redisplayed if they are received from user input. For example, encoding the script tag ensures a browser will display <script> but not execute it. In conjunction to encoding, it is important that the webpages always define their character set so the browser won't interpret special character encodings from other character sets.

Related Questions

Navigate

• Browse (All)
• Browse M
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.