You are barking up the wrong tree. SQL injection is a coding issue, tell your devs to use parameterized queries.

-phil
@bsdwiz

On Feb 4, 2013, at 4:56 PM, Infosec infosecm@gmail.com wrote:

I second that notion.

https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

• Jim

I know SQL injection is code issue.

The purpose of my question is, why three tiers is more secure than two tiers?
What three-tier will protected me from?

Than you all.

On Feb 5, 2013, at 3:51 AM, Jim Manico jim@manico.net wrote:

Consider:
http://searchsecurity.techtarget.com/tip/Separation-of-duties
http://www.cpd.iit.edu/netsecure08/ROBERT_RANDELL.pdf

"We can't solve problems by using the same kind of thinking we used when we created them." - Albert Einstein

-----Original Message-----
From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Infosec
Sent: Monday, February 04, 2013 6:59 PM
To: Jim Manico
Cc: websecurity@lists.webappsec.org; Phillip Gonzalez
Subject: Re: [WEB SECURITY] SQL injection and N tier Architecture

I know SQL injection is code issue.

The purpose of my question is, why three tiers is more secure than two tiers?
What three-tier will protected me from?

Than you all.

On Feb 5, 2013, at 3:51 AM, Jim Manico jim@manico.net wrote:

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Hello!

It depends! And I think you mean DMZ architecture as well, right?

When you have a structure with 3 tiers, in case some attacker
compromises the web application layer, if it configured properly he
wouldn't have access to the database (in theory) and access to
appserver will be restricted. If he compromises the application server
through webapp, big chances he gets access to the database.
If you web application layer is isolated on a DMZ and an attacker
compromises it, then he would be isolated in DMZ (theory and depending
on proper configuration). If he compromises your application (app
server) and if your App is in internal network along with your
database, then he would compromise not only your app but probably your
database and even your internal network.

Talking specific about SQL injection, it doesn't add any kind of
protection. As said before, prepared statements are the solution.

TH3D34D

On Mon, Feb 4, 2013 at 10:59 PM, Infosec infosecm@gmail.com wrote:

Hi,

There is a statement in your question that made me courious: is there any
published, numeric evidence that multi-tiered are less prone to sql
injections? This is the kind of recommendation I see people do all the time
based on - supposedly - better practices.

Since the flaw that allows a sql injection is always at the server with
direct access to the database, it makes no sense to me that additional
layers would make any difference in the overall hability to withstand an
attacker.

If anything, developers in charge of those intermediate layers are less
likely to implement proper input sanitization, since they it is not "their"
code that'll be blamed for any incident... OTOH, the "backend" developers
often assume that the middle tier will do all validation, a scenario prone
to massive breaches.

You can recommend a multi-tiered architecture - but not using sql
injection "resistance" as an argument. For instance, a front-end server
might be more exposed to infra-structure issues, so if an attacker gets
access to it, he/she would automatically get access to the database too,
whereas in the multitiered case another successful attack would be required
to reach the database.

Note, however, that if the middle tier is owned by the attacker, sql
injections may not be necessary at all. He/she will act as a
men-in-the-middle, manipulating all data that flows through at his/her will.
Em 04/02/2013 21:11, "Infosec" infosecm@gmail.com escreveu:

Hey there!

I believe he's trying to ask the following:

Why using a 3-tier scheme if with an SQL injection issue the attacker is able to "takeover" the DB, or with a Command injection control the App Server... and/or some kind of vulnerability like the one for Apache you can play with the Web Server infra?

Maybe he's wondering that... don't really know..

cheers, Nahu.-

On Feb 4, 2013, at 9:51 PM, Jim Manico jim@manico.net wrote:

Hi,

Separating the web server from application server adds almost zero
practical security. Attacks against the application - such as SQL
injection - will simply pass through the web server, and have the same
impact at the application layer. Attacks against the web server may be
slightly mitigated, but the impact of a compromised web server is still
serious, and web server vulnerabilities are now rare - so this doesn't
help you much either.

It's notable that .Net (unlike Java) never persued the approach of
separating web and application server.

A variation of the three tier archiecture that does add some security is
to replace the web server with a web app firewall.

Paul

On 04/02/2013 22:56, Infosec wrote:

application security.

--
Pentest - The Application Security Specialists

Paul Johnston - IT Security Consultant / Tiger SST
PenTest Limited - ISO 9001 (44/100/107029) / ISO 27001 (IS 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

On 5 Feb 2013, at 09:10, Paul Johnston paul.johnston@pentest.co.uk wrote:

Separating the different tiers does have benefits though, as with everything a lot depends on your particular application and any vulnerabilities it may have. The main things which spring to mind with regards to separating your web/app layer from your database is mitigation from attacks where you can leverage SQL Injection to write content into the web server Document Root or some other web accessible location. This, in my experience, is one of the quickest ways to gain flexible, arbitrary/shell access to a host.

If you separate this attack becomes infeasible or at least, much harder. Depending on how you segment your network it should also mean you can prevent outbound connections from your database server to the Internet. This gives you a reasonable degree of protection from reverse shells, etc.

Separating the web and app layers is a slightly different proposition and for me the benefits are even more dependent on your particular environment. A simple example would be those companies who might run something like Tomcat/JBoss and want to use the web/jmx console. By deploying the app layer to a separate host you can gain more network layer control over who can access those admin interfaces. There is significantly less risk than hosting it on an Internet-facing server. Less potential for human error exposing it accidentally to the horde of bots crawling for /admin, etc.

Bottom line is, separating out does not solve security problems per se, but it gives you options and raises the bar. The longer you can keep an attacker busy and the noisier you can make them once they've got an initial toehold in your app, the more chance you've got of reducing the impact of the attack.

My 2p.

Marc