Joseph Sinclair gives us the experiential slant, as usual!
*
*
I like the full set of Backend tools from OWASP:
http://www.owasp.org/index.php/OWASP_Backend_Security_Project_Tools i.e.
SQL Dumper
I really like the OWASP site for their comprehensive study of this subject:
http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection#How_to_Locate_Potentially_Vulnerable_Code
and:
http://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
which covers the various types and includes examples and code. Much of this
came out of Google Summer of code 2005, I believe.
And Webgoat project from OWASP is really powerful if you are using J2EE
application servers:
http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
If you like command line and simplicity try:
SQLscan.py is a great tool as in simple union join injection testing:
*python SQLscan.py -g inurl:’.gov’ 200 -s
‘/index.php?offset=-1/**/UNION/**/SELECT/**/1,2,concat(password)/**/FROM/**/TABLE/*’
-write sql_found.txt -v*
On Tue, Dec 1, 2009 at 8:53 PM, Joseph Sinclair
<
plug-discussion@stcaz.net>wrote:
> It's not going to find everything, and it's definitely not a
> fully-automated tool, but I find the SQLInjectMe plugin for Firefox to be a
> very useful tool for SQL injection testing.
>
> For more automated scanning, you might try Wikto (
> http://www.sensepost.com/research/wikto/), although I don't know much
> about it...
>
> Joe wrote:
> > Hey all,
> >
> > Can anyone (Lisa, I'm looking in your direction) recommend a decent SQL
> > injection scanner? I don't really care if it's server-side or
> > client-side since it's my server, and I don't need to *exploit* the
> > injection points, I just need an easy way to find them. I'd like it to
> > be easy to figure out, generate output or reports that are easy to
> > follow and not require too much to be installed on the server.
>
> I suggest that you test the way "they" will.
> > The reason I'm looking for something is that the server on which my
> > company hosts its websites has been compromised and I've been putting in
> > some considerable hours trying to fix things. I've removed malicious
> > scripts, fixed or removed the exploited code and changed all of our
> > passwords (from ssh to mysql to user accounts).
>
Keyloggers, puppet or cfengine might assist to trap them in real time, or
annoy them by restoring all the files changed on a server every few
minutes?
>
>
> Today, I happened to catch a SQL injection scan and now I'm trying to
> > look down that path some more. Basically, they used one of our (many)
> > poorly escaped queries to poll password data for our site login (among
> > other things). Luckily, I shut the scan down before they got the
> > passwords so I didn't have to have users reset them *again*.
>
> UG! Did you IPTABLE/ACL their source subnets?
Generally doing that you see the same traffic from another source IP, as
they usually attack from many sites, but watching logs for a string that
matches the original signature (like SNORT inline would) and automagically
iptable denying them, might help for the immediate, while you get it
together to run a full scan and get the developers and dba's to evaluate the
results. That bash shell script is easy to build integrated with iptables.
> > I've cleaned up a bunch of the sql code over the past could days, but
> > I'm wondering if there's a way for me to scan for injections myself and
> > attack code that is "more vulnerable" than others. I found sqlsus
> > (http://sqlsus.sourceforge.net/), which looked pretty impressive, but it
> > didn't run properly and it wasn't really a scanning tool so much as it
> > was an exploiting tool. I also found Pixy
> > (http://pixybox.seclab.tuwien.ac.at/pixy/), which looked pretty
> > comprehensive, but the output looked a little intimidating. Plus, the
> > little I read of the docs wasn't really clear about how to actually use
> it.
> >
> > Anything else anyone would recommend?
>
> Go through the full list of exploits and check your installations against
the known holes by version. Then start with the code. Many PCI compliant
applications must purchase a layer 7 application switch because code
rewrites are too invasive.
I would start with the comprehesive examples from OWASP.
> -Joe
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
--
Skype: (623)239-3392
AT&T: (503)754-4452
www.it-clowns.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)