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

["bryan allott" <homegrown () bryanallott net>]

sadly.. no.
it was for an online booking application for a local movie house.... 
available on a public website for all to see and book on.

i use the site often to book movies and was alerted to it becos we use the 
site often and it recently was revamped.
and so the new look and feel was WAY better than their last site and we were 
curious about how they were doing everything.. 'cos it really is quite 
slick, on the front end.

and that's when we uncovered the form requests [Fiddler]..

aahh.. so THAT's how u do it? send through the SQL and have the server 
execute whatever you give it and hope and pray the SQL is well-intentioned.

strangely enough, they were hacked 2 weeks ago with someone having fun and 
changing the titles and synopsis of some of the movies- i wonder how they 
managed that? *sic*


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


Of course there really are cases of (internal) applications where the
entire user population is assumed to have direct backend access to the
database anyway, and the application is just an improved interface to
save people the time of writing the SQL themselves. Maybe this was one
of those?

> -----Original Message-----
> From: bryan allott [mailto:homegrown () bryanallott net]
> Sent: Friday, October 06, 2006 02:25
> To: bugtraq () cgisecurity net; Will Jefferies
> Cc: Nish Bhalla; Erez Metula; Ory Segal;
> webappsec () securityfocus com; websecurity () webappsec org
> Subject: 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=70150
> 0000008YSz
> >
> --------------------------------------------------------------
> ------------
> >
> >
> >
>
>
> --------------------------------------------------------------
> --------------
> 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
--------------------------------------------------------------------------