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
--------------------------------------------------------------------------
