WebApp Sec mailing list archives

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


From: "Jeff Robertson" <jeff.robertson () digitalinsight com>
Date: Fri, 6 Oct 2006 08:10:33 -0400

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


Current thread: