Developing secure web applications

Many of the tra­di­tional soft­ware engi­neer­ing plat­forms have well laid out secu­rity gotchas and how to get around them or develop robust apps. Web devel­op­ment with all the vari­ety of options avail­able for devel­op­ment (JSP/J2EE, PHP, Perl, C#/VB.Net, Python etc etc) does not have this luxury..

Many of the tra­di­tional soft­ware engi­neer­ing plat­forms have well laid out secu­rity gotchas and how to get around them or develop robust apps. Web devel­op­ment with all the vari­ety of options avail­able for devel­op­ment (JSP/J2EE, PHP, Perl, C#/VB.Net, Python etc etc) does not have this lux­ury despite the vul­ner­a­bil­i­ties we keep hear­ing about almost every day. The Open Web Appli­ca­tion Secu­rity Project has a very decent list­ing of the "The Top Ten Web Appli­ca­tion Secu­rity Vul­ner­a­bil­i­ties" [PDF], while Developer.com offers some guid­ance as Best Prac­tices.

Other than the user inter­face and the realms of oper­a­tion, there isn't much dif­fer­ence between tra­di­tional (client server or desk­top) devel­op­ment and cod­ing for the web. The math is the same, the same gen­eral prin­ci­ples apply to both. Infact the web deserves more care­ful atten­tion to each and every line b'cos it's so exposed (and servers pro­vide a sin­gle point of failure/breach). In gen­eral, it is a mat­ter of com­mon sense. For instance, some things you can do to ensure safer code:

• Always ini­tial­ize all your vari­ables. If you don't ini­tial­ize them, many web script­ing lan­guages will allow vari­ables to be passed through the URL.
• For sen­si­tive data, it is prefer­able to pass vari­ables using POST and ensur­ing your script is retriev­ing them through POST (GET is faster for basic things but all the data is passed through the GET stream is actu­ally vis­i­ble over the web).
• PHP also allows you to access GET/POST val­ues using $var­Name directly so for exam­ple if your script has:

  shell_exec('dir *.'.$exten­sion); // get files with $extension

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

• When writ­ing SQL queries, be wary of 'SQL injec­tion' attacks. Search google for more, but in brief always escape user data (through GET or POST) — PHP offers the addslashes function.
• When using ses­sions, make sure ses­sion IDs are not brute force­able (don't use incre­men­tal ses­sion IDs ex xxx001, xxx002…, keep them long and use strong ran­dom­ness or a strong hash­ing, set an appro­r­i­ate expi­ra­tion time). Even Hot­mail at one point was vul­ner­a­ble to ses­sion hijack­ing and many sites still don't pay care­ful atten­tion (google for ses­sion hijack­ing — there's more than the obvi­ous hacks). For instance, I can use XSS (cross-site script­ing) to get some­one else's cookie for a domain, and replay­ing it to that domain, pos­ing to be that per­son, and hence log­ging in as him. Or man­u­ally edit­ing my own cookie and chang­ing it's expi­ra­tion time to keep my ses­sion alive for longer than intended peri­ods etc.
• Another inter­est­ing one I learnt of recently was 'Tim­ing attacks' — seek­ing infor­ma­tion based solely on the response/request tim­ing. Ex: if you run an applet off my site which loads Amazon's logo, I can mea­sure the time taken for the logo to load and com­pare it with your con­nec­tion speed. If the logo loads in a cou­pld of microsec­onds, then it prob­a­bly loaded from your cache and that means you have been to ama­zon recently enough for it to be in your cache. It's a naive exam­ple but it illus­trates the principle.
• When writ­ing OO code, you should develop a good under­stand­ing of vari­able scop­ing. An inher­ently good design can elim­i­nate most poten­tial secu­rity prob­lems from the start.

It goes with­out say­ing that a sin­gle weak­ness in your sys­tem or any of its ser­vices will exposes the whole sys­tem and all lengths you might have gone through to secure it might would go to waste. Fol­low the bug­traq for all soft­ware you are run­ning and occa­sion­ally visit the vendor's web­site for secu­rity updates/patches.