Paj's Home: Security: Web Applications

Web Applications

(Under construction)

Introduction

Security on the web is relatively immature, and not widely embedded in development processes. With so many teams building web applications, and these performing critical functions such as online banking, this vector poses a major avenue of attack. These risks generally only apply to dynamic web sites - sites where there is server-side programming. Static websites have very few technical security risks. I think of sites as being in one of three levels of criticality:

Low	These sites, such as message boards, or simple bespoke systems don't perform any critical functions. Still, security problems that allow the server to be compromised are a significant concern. And in such applications, such vulnerabilities are not uncommon.
Medium	Online shopping, insurance sales, etc. These have the basics covered, but subtle issues may remain, such as parameter tampering
High	e.g. online banking. The server and application are well secured. But users are still vulnerable - to phishing and trojans.

Solutions

How to go from low to medium: Developer rules Use SQL bind params Careful with xpath Don't do other stuff - call shell, etc. Testing black box / code review How to go from medium to high Much harder! Define the objectives: Server can't be directly attacked (that's a req for low too) Server can't cause unwanted actions (e.g. mail relay, proxy) Don't give away any information, e.g. if an email address corresponds to a user Site is "secure" even when malicious site open in another browser window Auth is "secure" i.e. password lockouts, etc. (auth wouldn't generally exist on low) forgotten password People can only access intended stuff Don't leave a trace on a cyber cafe Don't leak info in comments and such Can't help a phishing attack (e.g. redirect) Three prongs Consider security in design (i.e. threat modelling) Secure coding guidelines Testing Short term: developer training, threat modelling, pen testing, web app firewall Medium term: security in frameworks Long term: changes to technologies.

High Risk Sites

Or, how do you fix phishing and trojans? 1) User education. There is good advice for phishing (bookmarks/type in address). Only solid advice for trojans (separate classifications) is not that practical 1a) Aids to user education - anti phishing bar, high assurance ssl 2) Strengthen authentication. Not a complete fix, but raises the bar. Smart cards and SSL certs can prevent phishing. Issuing a physical device, or re-using one (mobile phone) 3) Risk assessment with additional authentication. Again, doesn't prevent "Just in time attacks" 4) Separate device that displays transaction details. Not many options, but mobile phone is one. Or a device that reads a barcode off the screen, or one you just type numbers into Most practical fix is using phone Detective controls - user notification

An idea: Unicode syntax characters

Many attacks are injection attacks - they work by injecting a character with syntax meaning to cause malicious effect. One of the problems preventing such attacks is that these characters are widely used. For example, in HTML, ampersand (&) is a syntax character, and it's also often used in normal text. The general solution to this is escaping such characters, but this gets messy.

The idea is to allocate some new unicode characters who's sole role is to be syntax characters; they would never appear in normal text. An escaping mechanism will still be required, in the case that syntax characters needed to appear as their character from (rather than as they function they provide), e.g. source code being display in a web page. To do this neatly, allocate some more characters, to represent escaped forms.

Perhaps the characters could be: syntax-character, alternate-syntax-character, left-syntax-character and right-syntax-character. These would be rendered differently depending on the context; perhaps in HTML as single quite, double quote, less-than sign and greater-than sign. There would also be syntax-character-escaped, alternate-syntax-character-escaped, etc. And syntax-character-escaped2, etc. and syntax-character-escaped3, etc.

Random Notes

There's direct server attacks (sql injection, parameter tampering, file upload flaws) And user trickery attacks, from phishing through xss And stuff like harvesting email addresses, abusing server resources, etc. WAFs IPS Frameworks with built-in security Code auditing / pen test / etc. Users can do their bit certain precautions protect against CSRF, some XSS, etc.

Recommended: Authentication and Session Management on the Web - I wrote this paper as part of my GSEC certification. It is a detailed look at some aspects of web application security.

IE Disclosure - Each time you visit a website, Internet Explorer gives out more information than you think.

http://www.justinclarke.com/security/ienterceptor.py http://portal.spidynamics.com/blogs/msutton/archive/2006/09/26/How-Prevalent-Are-SQL-Injection-Vulnerabilities_3F00_.aspx http://jeremiahgrossman.blogspot.com/2006/10/web-application-security-professionals.html In terms of the web application, first be sure to clarify exactly what you're covering. Just the user facing app? or is there an administration section as well? Often there can be lots of hidden parts of a site, e.g. for online banking there can be many different account types supported - they need to give you credentials which cover all the types that are in scope. There are a few practical questions: 1) Black box application test, or code review? I wouldn't recommend a purely black box test - at least give the testers credentials, and some design info. 2) Test against development or live? Testing against a pre-production environment is usually best. 3) Is it just technical app testing, or does it include things like the testers social engineering your help desk? This is more an "ass covering" question than anything; not expecting client to want social engineering. In terms of sizing, I've generally found asking for numbers of dynamic pages and forms is a bit futile; I rarely get accurate answers, and they have limited utility. I'm fortunate, working in a in-house team without cross-charge - accurate estimates are not required. I simply rate jobs as little (2 days) or big (5 days) and if I don't finish, just ask for more time. If you need an accurate estimate the best approach is to get credentials and have a look round the application yourself. In terms of reviewing the web server, there's a whole lot here: Patch / vulnerability scan of the OS (like Nessus/Foundstone) Config review of web server Config review of application server Quite often organisations will already have a decent setup for patch scanning all their servers, so you can skip the first one. One important point: while app scanning on pre-prod is usually ok (because code deployments tend to be well controlled), infrastructure type scanning is usually best done on live, unless you're happy with their controls to ensure consistent configuration between pre-prod and live. Quality scoping is a mix of technical knowledge, understanding the client's business, and (for consultancies) sales. If you get the opportunity, shadow someone experienced doing a scoping meeting.