I’m without many words for this. Sadly, the lyrics are accurate, so I can’t find much fault.

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

Chris over at css-tricks.com made a common sense post today -

…It’s the same thing for web designers. Most of us maintain several different websites for several different clients. To the client, their website is their whole world, so it makes perfect sense to them when they shoot you an email asking you to change a date quick. But when we open that email, we get the uhmmmmmmm….what feeling.

I would much prefer being treated like a six year old. Not being talked down to, just being VERY VERY clear about what is needed:

• What page needs changing (URL link!)
• Does it appear in multiple places?
• What does is say now?
• What should it say?
• When does it need to be done?

http://css-tricks.com/need-something-changed-on-your-website-treat-me-like-a-six-year-old-really/
I have felt a little bad in the past about getting all of this information from the client. It can be easy from them to toss a quick change over without many extras. The truth is, we can’t read minds and without this type of information we can not be sure we’ll actually be fixing the problem.

It may be time to formilize this into a pdf template and force each question to be answered for all changes going forward.

Here’s a few SEO resources to check out:

• http://www.organicseo.org/
• http://website.grader.com/
• http://www.mattcutts.com/blog/
• http://webconfs.com/
• http://www.seomoz.org/article/search-ranking-factors
• http://searchenginewatch.com/363264

http://lurkertech.com/buzzword-bingo/

Unfortunately, no one in the office won today. We did have 4-5 blocks covered during a short interview.

My baseball feaver is in full force, and after a hour of downtime today I’m now commited to anther fantasy league. I’m sure I’ll grow tired of the required work, but maybe my draft went good.

I think the fantasy league teams has been a pretty effective resource to balance the current extreme workload and has helped to keep me remain sane. I’m trying to handle the constant scope changes with my current project better than I have the least few weeks. It may seem counter intuative to add additional stuff to keep up with, but at this point why not give it a shot?!

OK. I’m going to try this blogging stuff again. Not for the marginal value to the public, but rather it’ll give me a place to blow off some steam.