Re: [WEB SECURITY] Re: SQL In the Request

source control integration and analyzing is definitely an interesting angle- 
and like most things implemented properly could be quite effective.
the particular issue which started this thread off..
[the SWF constructs the SQL and then posts the SQL as part of the request to 
the server in plain text]..
the entire application was architected to function like that intentionally- 
not just a case of a developer slipping in questionable code.
... so, we managed to track down the lead architect for that particular 
application and gave him a friendly call and pointed out if he was indeed
aware of the design he's chosen and it's consequences... his response:
the user only has SELECT access on the database anyways so it's not really a 
threat.
:o -a quick demo would shatter that myth but i don't think they're actually 
interested... {sigh}
so agreed, the layered approach to babysitting is needed.. but it's also not 
just the traditional developers, as in this case.
there's also this gap with flash designers who know some actionscript and 
have a good commercial idea which looks very cool but... yikes!
they come from a completely diff background and their 
"language/tools/compilers" don't fit the mould of "sourcecode" per se.
they too need to be roped into awareness and accommodated...

----- Original Message ----- 
From: <bugtraq@cgisecurity.net>
To: "Will Jefferies" <wjefferies@fncinc.com>
Cc: "Nish Bhalla" <nish@securitycompass.com>; "Erez Metula" 
<erezmetula@2bsecure.co.il>; "Ory Segal" <osegal@watchfire.com>; "bryan 
allott" <homegrown@bryanallott.net>; <webappsec@securityfocus.com>; 
<websecurity@webappsec.org>
Sent: Thursday, October 05, 2006 10:00 PM
Subject: Re: [WEB SECURITY] Re: SQL In the Request


> The longer I'm in this industry the more I'm thinking that educating 
> developers is like trying to
> stop the flow of illegal drugs. Sure you'll bust a few people, but a new 
> crop is always around the corner.
> I am thinking that we need to continue educating people however have a 
> layered approach to 'babysitting' them.
>
>
> Better Frameworks/Libraries/API's
> Providing easy to use API's that make 'screwing up' more difficult I think 
> is something that we need to continue
> working on. Yes you always risk those being dependant on something or not 
> fully understanding it but this is always
> going to happen to newbie's. Good developers like to understand what's 
> going on and this is something you learn with experience.
> Unfortunately until people are educated and have this experience they make 
> the same mistakes over and over again.
> Babysitting the majority from opening up risk and providing the more 
> experienced alternatives is something I think that we
> need to strive for. I think .NET is a good start in this direction however 
> doesn't address other languages.
> CERT recently released the Managed String library 
> (http://www.cert.org/secure-coding/managedstring.html)
> which is a good start for C however I think the industry as a whole really 
> needs to start focusing on creating and enforcing
> the usage of 'security helper' libraries.
>
> ?Source Control?
> We all know that source code analyzers need some work but can iron out the 
> common stuff. The problem is
> that if you don't use them you aren't going to find any issues unless you 
> have an extensive code
> review process. Simply put this isn't commonplace and is rather expensive. 
> Enforcing coding practices
> on the source control provider and preventing/alerting to the checking in 
> of 'suspect' code is something I feel requires more open
> discussion. Back to my statement above if a newbie developer checks in bad 
> code they aren't going to know its bad, and may not
> have someone reviewing it and identifying the problem until it is to late. 
> Preventing the usage of certain libraries
> in conjunction hybrid source code analyzer I think is something we really 
> need to start investigating/talking about.
> I'm not saying we'd block the code, obviously we'd need something 
> configurable to monitor and inform a project manager/architect
> and this wouldn't be a magic bullet to all development styles, but would 
> catch some low hanging fruit.
>
> My $3.50
> Comments/Flames welcome.
>
> - Robert
> http://www.cgisecurity.com/ Application Security news
> http://www.cgisecurity.com/index.rss [RSS Feed]
>
>
> > I see this occasionally.  It normally comes from an
> > amateur-trying-to-be-a-professional.  Indeed, developer education is
> > needed badly.
> >
> > -----Original Message-----
> > From: Nish Bhalla [mailto:nish@securitycompass.com]=20
> > Sent: Thursday, October 05, 2006 12:26 PM
> > To: 'Erez Metula'; 'Ory Segal'; 'bryan allott';
> > webappsec@securityfocus.com; websecurity@webappsec.org
> > Subject: RE: [WEB SECURITY] Re: SQL In the Request
> >
> > Well funny thing is that I have seen a couple of seminar sites titled
> > "Security for Developers" and one other Computer Security Conferences
> > website that are vulnerable to the exact same SQL Injection
> > vulnerability. I
> > am surprized how people hold conferences on security and don't even do
> > basic
> > security checks.
> >
> > Nish.
> >
> > =20
> > -----Original Message-----
> > From: Erez Metula [mailto:erezmetula@2bsecure.co.il]=20
> > Sent: Thursday, October 05, 2006 1:01 PM
> > To: Ory Segal; bryan allott; webappsec@securityfocus.com;
> > websecurity@webappsec.org
> > Subject: RE: [WEB SECURITY] Re: SQL In the Request
> >
> > Just to add another dumb example from real life, I did an application
> > assessment a couple of months ago that had a page like this:
> >
> > http://AppName/QueryDB.jsp?sql=3Dsql_query
> >
> > it can't be worse than that..
> >
> > ________________________________
> >
> >
> > Erez Metula, CISSP   =20
> > Application Security Department Manager
> > Security Software Engineer
> > E-Mail:  erezmetula@2bsecure.co.il      Mobile:  972-54-2108830
> > Office: 972-39007530    =20
> > =20
> >
> > -----Original Message-----
> > From: Ory Segal [mailto:osegal@watchfire.com]
> > Sent: Thursday, October 05, 2006 6:38 PM
> > To: bryan allott; webappsec@securityfocus.com; websecurity@webappsec.org
> > Subject: RE: [WEB SECURITY] Re: SQL In the Request
> >
> > Hi,
> >
> > I actually saw this kind of blasphemy several years ago -- an
> > application
> > that builds a SQL query using client-side JavaScript. The complete SQL
> > query
> > was then passed as a hidden parameter to the web application...
> >
> > Go figure...
> >
> > -Ory Segal
> > http://www.watchfire.com
> >  =20
> >
> >
> > -----Original Message-----
> > From: bryan allott [mailto:homegrown@bryanallott.net]
> > Sent: Thursday, October 05, 2006 5:35 PM
> > To: webappsec@securityfocus.com; websecurity@webappsec.org
> > Subject: [WEB SECURITY] Re: SQL In the Request
> >
> >
> > Just when i thought i had seen it all... -i come across a site which
> > passes in the following as part of the REQUEST..
> > yes, the SWF builds a request and sends it through to a php server... in
> > plain text.
> >
> > POST /flashsql.php?id=3D106 HTTP/1.1
> >
> > =3D QUERYSTRING =3D=3D=3D=3D
> >  id=3D106
> >
> > =3D BODY =3D=3D=3D=3D
> >  host=3D<HOSTNAME>
> >  sql_=3DSELECT DISTINCT(movies.id), movies.name, filename FROM movies 
> > LEFT
> > JOIN groups_movies ON (movies.id =3D groups_movies.movie_id) LEFT JOIN
> > groups ON (groups.id =3D groups_movies.group_id) LEFT JOIN files_groups 
> > ON
> > (groups.id =3D files_groups.group_id) LEFT JOIN files ON (files.id =3D
> > files_groups.file_id) WHERE movies.id IN(155,150,52,149,134,133,76) AND
> > files.file_type_id=3D9 ORDER BY movies.id
> >  dat=3Dsk_cms
> >
> > is there anyway that this can be "acceptable" ?=20
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > ----
> > The Web Security Mailing List:=20
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives:=20
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
> >
> > ------------------------------------------------------------------------
> > ----
> > The Web Security Mailing List:=20
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives:=20
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
> > ------------------------------------------------------------------------
> > ----
> > The Web Security Mailing List:=20
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives:=20
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
> >
> > ------------------------------------------------------------------------
> > ----
> > The Web Security Mailing List:=20
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives:=20
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> > Confidentiality Notice: This message is for the sole use of the intended 
> > re=
> > cipient(s).
> > It may contain confidential or proprietary information and may be subject 
> > t=
> > o the
> > attorney-client privilege or other confidentiality protections. If this 
> > mes=
> > sage was
> > misdirected, neither FNC Holding Company, Inc. nor any of its 
> > subsidiaries =
> > waive any
> > confidentiality, privilege, or trade secrets. If you are not a designated 
> > r=
> > ecipient,
> > you may not review, print, copy, retransmit, disseminate, or otherwise 
> > use =
> > this message.=20
> > If you have received this message in error, please notify the sender by 
> > rep=
> > ly e-mail=20
> > and delete this message.
> >
> > ----------------------------------------------------------------------------
> > The Web Security Mailing List:
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>
> -------------------------------------------------------------------------
> Sponsored by: Watchfire
>
> Watchfire has new programs available for pen testers and consultants to
> use AppScan in client engagements. AppScan is the leading Web application
> assessment tool. Want to see it for yourself? Take a look today!
>
> https://www.watchfire.com/securearea/appscancamp.aspx?id=701500000008YSz
> --------------------------------------------------------------------------


-------------------------------------------------------------------------
Sponsored by: Watchfire

Watchfire has new programs available for pen testers and consultants to 
use AppScan in client engagements. AppScan is the leading Web application 
assessment tool. Want to see it for yourself? Take a look today!

https://www.watchfire.com/securearea/appscancamp.aspx?id=701500000008YSz
--------------------------------------------------------------------------