Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: ISA Server and SQL Injection

Subject: RE: ISA Server and SQL Injection
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


<Prev in Thread] Current Thread [Next in Thread>