Sniptools

Many of the traditional software engineering platforms have well laid out security gotchas and how to get around them or develop robust apps. Web development with all the variety of options available for development (JSP/J2EE, PHP, Perl, C#/VB.Net, Python etc etc) does not have this luxury..

Many of the traditional software engineering platforms have well laid out security gotchas and how to get around them or develop robust apps. Web development with all the variety of options available for development (JSP/J2EE, PHP, Perl, C#/VB.Net, Python etc etc) does not have this luxury despite the vulnerabilities we keep hearing about almost every day. The Open Web Application Security Project has a very decent listing of the “The Top Ten Web Application Security Vulnerabilities” [PDF], while Developer.com offers some guidance as Best Practices.

Other than the user interface and the realms of operation, there isn’t much difference between traditional (client server or desktop) development and coding for the web. The math is the same, the same general principles apply to both. Infact the web deserves more careful attention to each and every line b’cos it’s so exposed (and servers provide a single point of failure/breach). In general, it is a matter of common sense. For instance, some things you can do to ensure safer code:

• Always initialize all your variables. If you don’t initialize them, many web scripting languages will allow variables to be passed through the URL.
• For sensitive data, it is preferable to pass variables using POST and ensuring your script is retrieving them through POST (GET is faster for basic things but all the data is passed through the GET stream is actually visible over the web).
• PHP also allows you to access GET/POST values using $varName directly so for example if your script has:

  shell_exec(‘dir *.’.$extension); // get files with $extension

  where $extension is passed through POST/GET, then the user could call index.php?extension=|del%20*.*

• When writing SQL queries, be wary of ‘SQL injection’ attacks. Search google for more, but in brief always escape user data (through GET or POST) - PHP offers the addslashes function.
• When using sessions, make sure session IDs are not brute forceable (don’t use incremental session IDs ex xxx001, xxx002…, keep them long and use strong randomness or a strong hashing, set an approriate expiration time). Even Hotmail at one point was vulnerable to session hijacking and many sites still don’t pay careful attention (google for session hijacking - there’s more than the obvious hacks). For instance, I can use XSS (cross-site scripting) to get someone else’s cookie for a domain, and replaying it to that domain, posing to be that person, and hence logging in as him. Or manually editing my own cookie and changing it’s expiration time to keep my session alive for longer than intended periods etc.
• Another interesting one I learnt of recently was ‘Timing attacks’ - seeking information based solely on the response/request timing. Ex: if you run an applet off my site which loads Amazon’s logo, I can measure the time taken for the logo to load and compare it with your connection speed. If the logo loads in a coupld of microseconds, then it probably loaded from your cache and that means you have been to amazon recently enough for it to be in your cache. It’s a naive example but it illustrates the principle.
• When writing OO code, you should develop a good understanding of variable scoping. An inherently good design can eliminate most potential security problems from the start.

It goes without saying that a single weakness in your system or any of its services will exposes the whole system and all lengths you might have gone through to secure it might would go to waste. Follow the bugtraq for all software you are running and occasionally visit the vendor’s website for security updates/patches.

This post is tagged Musings