[FIXED] = no loger exploitable
[OPEN] = still exploitable. needs to be fixed.
A multi-line link defines post data is used to access the exploit. since ipb combines post data + get data, a combined link will be provided below.
SQL Injection:
[FIXED]
Loading a shout from the shoutbox
www.staredit.net/index.php?act=Shoutbox&view=saved&load=sql_query
[FIXED]
Linking to an affiliate
www.staredit.net/index.php?act=affiliate&code=01&id=sql_query
[FIXED]
Viewing a single shout
www.staredit.net/index.php?act=Shoutbox&shout=sql_query
[OPEN]
Donating an item to another member
www.staredit.net/index.php?act=store&CODE=do_donateitem
username=Pyro-Fire&message=msg&submit=Send&items%5B%5D=sql_query
www.staredit.net/index.php?act=store&CODE=do_donateitem&username=Pyro-Fire&message=msg&submit=Send&items%5B%5D=sql_query
Shoutbox should be fixed.
EDIT: Both fixed.
How exactly can you tell if one is exploitable or not?
http://en.wikipedia.org/wiki/SQL_injectionIt happens when inputs in forms or URLs aren't handled properly. It can get the person using it to generate an SQL error. If they input the right code into there, they can use it to make SQL queries (DELETE, DROP, TRUNCATE, for instance).
Why on earth would anything be scripted so that is possible in the first place?
Laziness or ignorance. It's quite easy to make a hole and not even know it... sometimes it can be quite complicated.
Easy example is having a drop down list like...
Select 1: Blue, Orange, Red.
And assume that because the user is limited to those three by html, the input wouldn't be anything other than that...
Sometimes it gets wild.
I'm not a php person but I'd assume that's what if statements are for.
Most of the time it seems to be certain characters used for syntax aren't parsed out or disabled or numerical inputs that will accept text.
Is there a simple way to add code at the top of index.php that will parse whatever form elements are being fed to index.php and take out anything that would be SQL injection?
I don't know exactly how it would look, but I'm thinknig something like an IF/ELSE that checks the post to see if it contains the text SQL, as all of the exploits would have to. Something like..
if ($_POST['']='SQL' || $_GET['']='SQL'; )
return $errorPage;
else ()
return $goodPage;
*Syphon hasn't written any php in a long, long time.
I've never done PHP, but it seems that with any CGI-based webscript you should be able to run a parse of the elements passed to the script before you do anything at all to the database.
DTBK, that's how it is... but that doesn't mean you still can't do injection. All the ' " < > / & % gets parsed to their html entity before any script can touch the input. That, by far, doesn't stop the holes though.
Is there any way to make a catch statement for each form value being passed to index.php that can tell whether the form value can execute an injection and then abort to an error page (skip the rest of the script) if so, or is it not possible to write an algorithm that can detect malicious input?
In CGI Python, which is more my forte, you can run a check on the elements of the form values from the cgi method, and if it is possible to detect SQL injections with a written algorithm than you could abort the process by not tripping a flag that the rest of the file requires. I would assume the same syntax effectively works in PHP, but what I don't know is if you can tell between queries and useful input for any form field with a blanket algorithm.
Psst, IP what did you do to the ACP to break the CSS and almost every form submit?
is anyone going to fix the latest sql injection?
QUOTE(DT_Battlekruser @ Jan 3 2007, 12:56 AM)
Psst, IP what did you do to the ACP to break the CSS and almost every form submit?
[right][snapback]609313[/snapback][/right]
Who cares, he fixed the favicon.