ASP APP Security - Hack Possible?

[thankgodfortektips]

Hi All,

I have developed an application (ASP and SQL 2000) that I have now got a few organizations using. I am just wondering the possibilities of getting hacked as I am wanted to change the app from running on local servers to being on a hosted server open to the world.

I have a log in page that sets a session variable. When the user goes to each page there is a lookup to the permissions table which in short has the userid and page name. If the userid isn't in the table with the current page name then the system logs them out.

Is there anything that I need to worry about as far as people gain access to the data? Does anyone know where I can find information about methods of hacking ASP applications?

Thanks!

 

[BigRed1212]

If you are constructing your query to the permissions table dynamically from query string data from a submitted form, then yes, you are probably vulnerable to an SQL injection attack.

As far as worrying about people gaining access to the data, I suppose it depends in part on what the data are. If the data are annual wooly caterpillar measurements then maybe you needn't worry, if the data are credit card numbers then yeah. Regardless, a hacker might not really care what your data are or even be after them if they were really just trying to use an SQL injection attack to get to the server. For some, the server access, not the database, is the prize.

I'm not the guy to ask about how to secure things, however.

 

[thankgodfortektips]

Thanks Big Red,

So how would you recommend I check the users permissions? I only know of a form that could be used to get the users input i.e. their username and password.

Thanks

 

[josver]

You should read up on "SQL injection" and "cross server scripting" attacks.
Both mean that an attacker tries to gain access to a database by filling in code in form fields, or sending code in the request.querystring object

a parameter id is an ideal candidate, but hackers try anything.

There is only one way to secure your site against this type of attack and that is :

NEVER feed field data directly into an SQL statement
CHECK the data for certain markers (like the sequence ';DECLARE) before doing anything with it.

The past year this type of attack is exploding. You might want to check your IIS logs for the above sequence

Google your way around a bit, you'll be surprised.

I've been recoding our apps for a while now, after one hacker got through

 

[BigRed1212]

So how would you recommend I check the users permissions? I only know of a form that could be used to get the users input i.e. their username and password.

Like I say, I'm not the big security guru like some of these folks.

I use Access so I'll talk in those terms. I don't know how to translate it to SQL 2000.

Say your login form page (login.asp) looks like this in part:

<form name="form" action="logincheck.asp" method="post">

<fieldset>
    <legend>Login</legend>

<label for="username"> Username:</label>
<input name="username" id="username" type="text" />
<br>
<label for="password"> Password:</label>
<input name="password" id="password" type="text" />

</fieldset>

<input name="Submit" value="Login" type="submit" />
</form>

And that logincheck.asp then uses Request.Form("username") and Request.Form("password") to construct an SQL statement in the ASP page that checks the database and gives a thumbs up or down. If I'm a hacker and I send the right commands to logincheck.asp I get into the database.

In Access, what one can do is create a procedure in the Access database and save it there. Then in the asp page, instead of doing something like:

Connection.Open(sConnString)
SQL1 = "UPDATE my_table Set bunch of SQL with stuff like WHERE userid=" & userid
Connection.execute(SQL1)

you do something like:

Set con = Server.CreateObject("ADODB.Connection")
con.Mode = 3
con.Open data_source
con.name_of_stored_procedure userid
con.Close
Set con = Nothing

That way the SQL statement can't be mucked with and any funky stuff that gets sent like ";Drop table" doesn't work. At least I don't think it does.

Like I say, the big boys do more than this I am sure and would scoff at this, but it is what I know and what I do and maybe you are closer to my level and will find it useful.

 

[Ovatvvon]

Like others are saying, use Stored Procs, limit the input of field/text length by truncating the inputs from the user on the server side before processing. For instance, for a "first name" field, maybe only select the LEFT 20 characters, and everything else is ignored. That limits the complexity of SQL Injection commands possible. You can also scan data from web forms (via code) for key words like SELECT, UPDATE, DELETE, INSERT, ADD, DROP, etc, and if they exist, either remove them, or, what I would do, is just cancel the the action altogether, and maybe even have a little fun with them like redirect the page over to FBI.gov or something. haha.

Anyway, on a separate note, instead of matching several ID's to each page (which is what it sounds like you're doing), you can grant "security levels" for each user (i.e. John is a security level 1, while Beth is security level 2, but Annabelle is a level 5, so she's an admin on the site), then just classify each page for what level it is depending on it's purpose, and location within the directory structure. That way, you only have to classify each user once, and specify each page once, instead of having one user listed over and over again for all the pages and/or having pages listed with many different people. This should cut down on the size of the database a bit, and possibly speed up transactions. If you're operating a small business, it probably won't matter for performance, but can make significant impacts if you work for a company like me who has over 70,000 employees.

It should cut down on duplicate data anyway, which makes your database more 'normalized'...which is usually a good thing.

Hope these comments help.





-Ovatvvon :-Q