i heard that it is possible to exeute commands through <FORM>s
-is this true?
-does it only take HTML?
-how do you stop it?
Printable View
i heard that it is possible to exeute commands through <FORM>s
-is this true?
-does it only take HTML?
-how do you stop it?
The only way that I know of that a form can execute a command is if you have a messed up CGI script that allows call out of the directory it is in (For example if I have a CGI script named f00 and it is set up to allow out of directory execution (for one reason or another) and say I put it in a form on my website)
Now say I am a l337 hacker (or just some stupid kiddie) I start trying random stuff until I come across an 'exploit' that actually works, say in the input of the text field I put ..%c0%af../winnt/system32/cmd.exe?/c+$command (standard unicode exploit) and I get a responce.... Well then any self respecting kiddie or whatever would try to get more information on the system ssothey would probably type in ..%c0%af../winnt/system32/ipconfig.exe which would execute IPconfig and reveal the IPs/hostnames of all the NIC's/computers hooked up to this computer.... I have made a post on this subject before, I cant find it at the moment..... As soon as I do ill re-post it hereCode:<form method="POST" action="http://myserver/cgi-bin/f00">
<input type="text" name="f00text" size="20">
<input type="submit" value="Submit" name="Submit">
<input type="reset" value="Reset" name="Reset"></p>
</form>
:D
EDIT: By the way, the way that a query is submitted to a cgi script or pretty much any other script is with ?'s for example if I put a value of 12345bbs in the f00text box the server would submit it as.... http://myserver/cgi-bin/f00?f00text=12345bbs
yes and no...what you are talking about..i think...is attacks through form submissions...these can be
buffer overflows...ie...sending a really long form submission which chokes a server and sometimes gives remote access and or control....these can be mitigated to a degree by having properly patched servers...one of the easiest ways of dealing with this is to explicity specify the size of the input field with maxlength...
/input type="text" value="myinput" size="10" maxlength="25"\ it's pretty hard to pull off a buffer overflow in 25 characters.
one of the least recognized attacks is on database driven sites...by creating a form submission in a certain ways it is possible to do nasty things to a backend database....like deleting and changing records...
Sample form
/form action ="nastySQL" method ="post"\
/input type="text" name="username" value="john@nowhere.com"\
/input type="text" name="password" value="fake' ; delete from users where email is not ' "\
//form\
when input the SQL will look something like this:
Select * from users
where username = 'john@nowhere.com' and password= 'fake'; delete from users where email is not ' '
which...in general...will delete all files in the table...this won't necessarily work as is...but you get the idea...
forms...especially forms running in front of a database MUST have some kind of filtering...you can do client side with javascript, but that will only stop the lamest kiddies...if you care at all about your data, you've got to have some kind of server side validation and filtering...i use both...
There are a variety of possible ways which people can potentially run remote commands from forms (or indeed non-form based dynamic web content)
Most of these are due to application bugs rather than exploits in particular server products.
Say someone makes a web site which uses forms like antionline, there are lots of things they can do wrong which will lead to potential security problems:
If a form parameter (or querystring parameter) is used to form part of a filename, they may forget to check it for special characters, so it may be possible to access files outside of the desired directory (f.e. by using ".." but that's not the only way).
If you open a file in perl, there are other worse things involving pipes :(
If you use a database management system to store information, which uses SQL, people often incorrectly escape (or simply fail to escape) strings being sent to the server. The user can (by various methods) send malicious commands to the server, in some cases resulting in a remote take-over of the server, but in other cases merely breaking the application.
Scripts which pass their data on to external program other than those mentioned often fail to check the data fully or escape it, this leads to similar, less common bugs.
In the past a common error was to incorrectly escape email addresses for sendmail (although this bug is now so old I doubt many systems are vulnerable)
Finally, a few scripts deliberately run the user's commands, for administrative purposes (or reporting in the case of SQL). If they can be accessed by unauthorised users, that would result in a security problem, obviously.
Oh! Thanks for reminfing me slarty!
When a user or a malicious hacker throws the webserver off the 'net (or crashes it) it is called DoS (Denial of Service) because they have effectively kept users from viewing that website... They are self-proclaimed internet censors :)