WebApp Sec mailing list archives
RE: ISA Server and SQL Injection
From: "Mark Curphey" <mark () curphey com>
Date: Wed, 23 Feb 2005 06:58:01 -0800
Paul, thanks for the reply -----Original Message----- From: Paul Johnston [mailto:paul () westpoint ltd uk] Sent: Wednesday, February 23, 2005 6:21 AM To: Mark Curphey Cc: 'Ofer Shezaf'; webappsec () securityfocus com Subject: Re: ISA Server and SQL Injection Mark, Thanks for sharing your thoughts. I think what you're saying boils down to "just get the code right". Curphey>No I am saying build secure software. There is much more to that than just getting the code right. Architecture and design, process, technology, operational management etc. Building a secure access layer doesn't (shouldn't IMHO) have to be on the network layer. Well, sure, if everyone did just get the code right then we wouldn't have these problems. But the point of defence in depth is to design a system that is secure, even if a few coding errors have been made. Curphey>Isn't that examples of an architectural concept called "compartmentalization" and "least privilege"? This should be present in every piece of software. Why push security control outside of the apps direct control into a network layer? It breaks every software architecture principle I have ever read by the gurus (BRJ etc)......building apps with compartments and running in sections of least privilege is common sense and builds depth in defense. With this in mind, app firewalls are a useful part of the arsenal. On a practical level, doing this gives more security than expending equivalent effort just on auditing the code. Curphey> I never said "just" audit code. Never. And BTW I ignored the other pettty personal attacks in a reply that have been going on for years and filed them in dev/null btw. Get over it and move on dude, it's ridiculous.
They have no hope whatsoever to protect a web application where say switching a name value pair gives you another persons account.
The current ones perhaps, but that's not an inherent limitation. Just like TCP/IP firewalls have become stateful, so will application firewalls. Say the field is "basketid", the app firewall starts by blocking ALL values of that. When a user requests a page with a link to a valid basketid for that user, the app firewall statefully adds that id to the whitelist for just that user. This way, if the parameter is vulnerable to tampering (e.g. it's sequential) the app firewall provides further protection. Curphey>Why push this out to a network layer? It breaks all software architecture theory. Why not do what you say in the app? It doesn't have to be the same component. Think MVC ;-) Ideally, the back-end application protects this by using 128-bit random numbers as IDs. The front-end app firewall provides further protection. Now, if EITHER of these protections fail, the resulting system is still secure. Curphey> For the record two key points. I never said they have no value. As part of a depth in defense strategy they MAY be appropriate. I said I would choose to implement things differently and wouldn't buy on but I come from a F100 type enterprise background where they just wouldn't work. In other environments I am sure they could. I was really pointing out you have choices. Code, framework, web server or network and the closer you are to the code the more control, precision and IMHO security you have. Software has to protect itself. Bottom line. Secondly I said I was looking to buy (or probably wait for Beretta http://www.zfish.co.uk/beretta/) an automated scanner. These things def have value to find low hanging fruit fast. But they don't find complex holes and def don't find MOST of the holes. We pointed all the major ones at Hacme Bank a while back and not single one got the or '1=1 SQL injection on the front page. In there defense it was so convoluted that it was excusable but tested against other apps they only find low / medium low hanging fruit (again IMHO). I am not saying they don't find lots of stuff. They do and they do that fast. They have exceptional value in that (and SPI which I saw again recently is a really nice tool and from what I have seen beats the competition with a stick) but that category of technology is not possible to find the complex flaws in bespoke web software. Regards, Paul -- Paul Johnston, GSEC Internet Security Specialist Westpoint Limited Albion Wharf, 19 Albion Street, Manchester, M1 5LN England Tel: +44 (0)161 237 1028 Fax: +44 (0)161 237 1031 email: paul () westpoint ltd uk web: www.westpoint.ltd.uk
Current thread:
- Re: storing SSNs, CCNs, password in the DB, (continued)
- Re: storing SSNs, CCNs, password in the DB Andrew van der Stock (Mar 01)
- Re: storing SSNs, CCNs, password in the DB Paul Johnston (Mar 01)
- Re: storing SSNs, CCNs, password in the DB Joseph Miller (Mar 01)
- Re: storing SSNs, CCNs, password in the DB Alvin Oga (Mar 01)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeff Williams (Feb 28)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeremiah Grossman (Mar 01)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeff Williams (Mar 01)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeremiah Grossman (Mar 01)
- Re: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Jeff Williams (Mar 01)
- Re: ISA Server and SQL Injection Paul Johnston (Feb 23)
- RE: ISA Server and SQL Injection Mark Curphey (Feb 23)
- Re: ISA Server and SQL Injection Paul Johnston (Feb 23)
- RE: ISA Server and SQL Injection Mark Curphey (Feb 23)
- Re: ISA Server and SQL Injection Paul Johnston (Feb 28)
- Re: ISA Server and SQL Injection Stephen de Vries (Feb 28)
- Re: ISA Server and SQL Injection Jan P. Monsch (Mar 01)
- Re: ISA Server and SQL Injection christopher (Mar 03)
- Re: ISA Server and SQL Injection Jan P. Monsch (Mar 03)
- Re: ISA Server and SQL Injection Paul Johnston (Mar 03)
- Object Caching with IE 6 XP SP2 Don Tuer (Feb 28)