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)
A form textarea field “About Me” is stored directing into the user’s profile. The user (“Attacker”) inputs the following:
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“.
Cross-Site Request Forgery (a.k.a. CSRF)
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.
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.
Multiple changes chained together help minimize, if not eliminate this attack.
- 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.
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.
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.
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:
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.
Via Wikipedia Entry:
$var = $_GET[“something”];
$_SESSION[“$var”] = $var2;
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.
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.
SELECT * FROM permissions where user_id=$_COOKIE[‘user_id’]
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.