I hope that those visitors who may be newer to development can learn how to keep all of our data safe on the web. I’m sure that those who’ve been doing this for awhile have seen all of this before. If enough people find this helpful, I may write up some additional segments in the future.
Cross-Site Scripting (a.k.a. XSS)
The Summary
XSS commonly occurs via a form input that contains malicious javascript/vbscript/flash that is not properly sanitized before use or storage. An example of this is entering a siplet of javascript into a textarea field which is in turn displayed as a profile field. In this example, when a visitor views the infected profile they will call the javascript and the script inside will be executed. This could be as simple as a alert box or as dangerous as a way to extract personal information.
Example
A form textarea field “About Me” is stored directing into the user’s profile. The user (“Attacker”) inputs the following:
<script type=”javascript”>alert(“Hi there)”);</script>
Visitors that request the user’s profile will now have a javascript popup with the message “Hi there”.
The Fix
All input data should be sanitized and validated before use or storage. If you’re using $_GET, $_POST directly, then you need to start over. There are many third party scripts that help you sanitize your data, but ultimately it is best practice to understand the sanitation methods in use before you just plug them in. There’s nothing worse than a false sense of security. At a minimum, I recommend running your site through the “Cheat Sheet“.
Deeper Reading
ha.ckers.org: XSS Test List, a.k.a Cheat Sheet
TestingSecurity.com: XSS Injection
Shiflett.org: XSS
MS TechNet: XSS Testing
Wikipedia Entry
Cross-Site Request Forgery (a.k.a. CSRF)
The Summary
Unlike XSS attacks, CSRF attacks frequently occur off of the target site. The idea of this attack is to exploit the trusted data stored in a user’s cookie data, bypassing login step and proceding to a desired action. This is possible when a site allows you to complete a action via query string data solely relying on login data contained within the cookie file.
Example
Knowing that you are a customer of XYZ Bank, an attacker attaches the follow image to a forum you visit:
<img src=”http://xyzbank.com/transfer?amount=500.00&account=0123456789″ />
If you have valid session data, and you bank has not protected itself from this attack, you just lost $500.00.
The Fix
Multiple changes chained together help minimize, if not eliminate this attack.
- First, if you’re using a general $_REQUEST variable for input, convert it to $_POST. The image stuffing method shown above works in part because the data is being passed as part of the $_GET data. Using $_REQUEST checks both the $_GET and $_POST datasets for field data and that leaves you (or the bank in this case) open to attack. Attacks via image tags will be blocked by this change, but Javascript attacks will still be possible.
- Secondly, use and read data not only in cookies, but also in the server session. Most importantly, when doing this make the login data in the session expire after a short amount of time (10-30 minutes). It’s standard practice for banks to do this today, and you should too.
Deeper Reading
CGISecurity.com: CSRF FAQ
Shiflett.org: CSRF
Wikipedia Entry
SQL Injection
The Summary
Like XSS, the root SQL Injection lies on using input data without sanitation. SQL Injection passes the input data into a database query, thus giving the user a means to connect directly to a otherwise private database. The types of data inputted is usually created in such a way, that a query is completed and an additional query is also run afterwords. An attacker can also utilize other SQL language commands, such as UNION to add sensitive data to a otherwise normal query.
Example
A corporate support forum allow customers to search the forum for their support topic. This field is passed into the following query:
SELECT * FROM forum_posts WHERE message LIKE ‘%<search_string>%’
Upon discovering this security problem, an attacker can craft the following search query:
anything%’; SELECT * FROM secret _passwords WHERE name NOT LIKE ‘%
Together, this forms the following query:
SELECT * FROM forum_posts WHERE message LIKE ‘%anything%’; SELECT * FROM secret _passwords WHERE name NOT LIKE ‘%%’
The query now will pull out everything in secret_passwords.
The Fix
While intense filter may make your database marginally safer, the absolute must is “escaping” the search data when making it part of the search query. Each language has it’s one functions or add on classes to accomplish this. The following is an example for php:
mysql_real_escape_string(<search_query>)
Deeper Reading
Wikipedia Entry
PHP.net Manual Entry
MSDN: Protecting ASP.net From Injection
Session Poisoning
The Summary
Session poisoning is similar to XSS, in that input data can be used to exploit the storage and use of said data. While XSS uses the re-display of this data in the browser, Session Poisoning relies on the use of unsanitized session data being used in code before information is displayed.
Example
Via Wikipedia Entry:
$var = $_GET["something"];
$_SESSION["$var"] = $var2;
The Fix
Like XSS, the fix for Session Poisoning is sanitizing user input. It is also suggested to validate and sanitize the data once more when retrieving data from the session. It may seem like a belt and suspenders approach, but it is possible to get data into a session that you did not sanitize. This can be seen most commonly with shared web hosts.
Deeper Reading
Zend.com: Session Management
Wikipedia Entry
Cookie Poisoning
The Summary
Cookie Poisoning relies on a website to full trust and fail to validate data retrieved from cookies. Cookie data may be edited to create attacks via SQL Injection, or when cookie data is solely relied upon for user authentication, to impersonate a user with elevated permissions.
Example
SELECT * FROM permissions where user_id=$_COOKIE['user_id']
The Fix
Once again, validate and sanitize your data. Additionally, don’t depend on cookies as your sole means of user authentication. Authentication should be comprised of both cookie and session data. Only store absolutely required data in a cookie and encrypt the data before storage where possible.
Deeper Reading
Security Focus: Penetration Testing (Part 3)
Wikipedia: HTTP Cookies
