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