Web Security Strategy – Hints?

Topic

New Reply

I have set up a website with a login page and currenlty it *kinda* works. If you successfully login, a session variable is created that stores the SessionID and then you get to the next page. On that page and others I test to see if the session variable is empty or not; if it’s not empy the page loads, otherwise you are told the session has expired or you need to login. The main thing I want to do is prevent people from bookmarking the pages after login.

If you quit IE altogher and restart it and try to bookmark in you can’t. However, if you go somewhere else and come back via bookmark, you’re in. Also, I noticed in my reference book that a cookie can be set to expire in a day or more and I’d like to limit the variable’s life time to something like 30 minutes.

So, in sum:
1) what’s a good way to send data from page to page without it being visible to the client? Cookies? Session Variables? Elves?
2) how to ensure that the user (ideally) can never ‘leave’ the system and come back behind the login via a bookmark? is there a xbrowser block bookmarks script that is available? Any other ideas on what might be an issue with ensuring that people have, indeed, logged in? Flags to a db perhaps?

TIA

Reply | Quote

Replies

When I wrote classic ASP applications I typically did something similar for page authentication, except I usually used an integer to indicate the user’s permission level (User, Admin, etc). Like your application, I would check for the absence or presence of the Session Variable on each page then redirect to the login page if needed.

Keep in mind that leaving your website does not necessarily end the session. The session will remain open for a default period of 20 minutes, depending on the value you’ve set in your IIS settings (Options tab on the Application Configuration dialog, after clicking the Configuration button on the Virtual Directory tab of a web application’s property page in IIS). Closing the browser DOES end the session. Unless you’re creating a persistent cookie, the temporary session cookie (holding the session variables) will expire when the session ends.

In Classic ASP one of the best way to persist state information from one page to the next is Session Variables – just remember to destroy them when they are no longer needed since they consume memory. You can use cookies for non-sensitive information such as a user’s site preferences and the like. NEVER store anything sensitive in a cookie!!!! (The only exception to that would be if you’ve used a highly secure encryption method.)

What do you mean by ‘leaving’ the system? Exiting the browser, or simply navigating to an outside page? It sounds like the current method you’re using will work for the former. As I stated above, navigating away from your site will not necessarily end the session. The user will technically be able to return until the session expires. You may consider setting the timeout to a much shorter value (1 or 2 minutes) and testing this.

Hope this helps

Reply | Quote

how are Session Variables used and how are they different from Cookies? If there is no relationship between SVs and bakery products, just tell me that so I will cease to feel confused.

I *think* that Session Variables are the way to go but I am a bit puzzled on how to use them. Can ya help?

Reply | Quote

Cookies can be used in 2 ways: Temporary and persistent. Temporary cookies are not assigned an expiration date and reside only in memory. These are lost at the end of a session. Persistent cookies are assigned an expiration date and are created as a text file on the client machine.

As I understand it, session variables function much like temporary cookies.

Try searching Google for “ASP Session Variable” and you’ll find a gold mine…

Reply | Quote

Cookies can be used in 2 ways: Temporary and persistent. Temporary cookies are not assigned an expiration date and reside only in memory. These are lost at the end of a session. Persistent cookies are assigned an expiration date and are created as a text file on the client machine.

As I understand it, session variables function much like temporary cookies.

Try searching Google for “ASP Session Variable” and you’ll find a gold mine…

Reply | Quote

how are Session Variables used and how are they different from Cookies? If there is no relationship between SVs and bakery products, just tell me that so I will cease to feel confused.

I *think* that Session Variables are the way to go but I am a bit puzzled on how to use them. Can ya help?

Reply | Quote

When I wrote classic ASP applications I typically did something similar for page authentication, except I usually used an integer to indicate the user’s permission level (User, Admin, etc). Like your application, I would check for the absence or presence of the Session Variable on each page then redirect to the login page if needed.

Keep in mind that leaving your website does not necessarily end the session. The session will remain open for a default period of 20 minutes, depending on the value you’ve set in your IIS settings (Options tab on the Application Configuration dialog, after clicking the Configuration button on the Virtual Directory tab of a web application’s property page in IIS). Closing the browser DOES end the session. Unless you’re creating a persistent cookie, the temporary session cookie (holding the session variables) will expire when the session ends.

In Classic ASP one of the best way to persist state information from one page to the next is Session Variables – just remember to destroy them when they are no longer needed since they consume memory. You can use cookies for non-sensitive information such as a user’s site preferences and the like. NEVER store anything sensitive in a cookie!!!! (The only exception to that would be if you’ve used a highly secure encryption method.)

What do you mean by ‘leaving’ the system? Exiting the browser, or simply navigating to an outside page? It sounds like the current method you’re using will work for the former. As I stated above, navigating away from your site will not necessarily end the session. The user will technically be able to return until the session expires. You may consider setting the timeout to a much shorter value (1 or 2 minutes) and testing this.

Hope this helps

Reply | Quote

> 1) what’s a good way to send data from page to page without it being visible to the client? Cookies? Session Variables? Elves?

This depends on what you mean by “visible” – available to the naked eye or discoverable with a bit of effort? Anything your page sends to the user can be discovered.

The ASP session key, which is stored by the browser as a session cookie, uniquely identifies that session. But you can corroborate it with information from the HTTP headers (e.g., IP Address, UserAgent string). However, ASP doesn’t run without it, so you do have to send that back and forth to use ASP (note: this is automatic). For other information, if it is sensitive, it does make sense to store it on the server. If you don’t like session variables, how about a database?

> 2) how to ensure that the user (ideally) can never ‘leave’ the system and come back behind the login via a bookmark?
> is there a xbrowser block bookmarks script that is available? Any other ideas on what might be an issue with ensuring
> that people have, indeed, logged in? Flags to a db perhaps?

One possibility is to check the HTTP_Referer property in your ASP page. This will be blank for bookmarks, unless the user intentionally fills in deceptive information. If the property shows an address on your server, it is likely that the person is navigating normally. If there is an address from somewhere else in cyberspace, you have something interesting to investigate.

Using JavaScript, you can inspect some information about the History object. Maybe if the immediately previous page in the History is not from your server, you could clear the page or refresh to the login screen? This wouldn’t prevent someone from using back to see pages they saw before, unless the browser failed to cache them in the first place. I haven’t looked into it, but I suspect that there are ways to both limit caching and detect refreshing.

Have fun!

Reply | Quote

thanks for your detailed response. I think I basically want to do this:

1. If a visitor goes thru the actual login page, that generates a session value loaded with *something*.
2. After passing thru the login successfully, all other pages have code to open/read the session value. If the session value is blank (meaning it never got loaded because the user didn’t go thru the login page) a ‘tut-tut’ page pops up telling the person they need to login or their session has expired.

I’m already doing this and it works alright. BUT, if the user logs in and preceedes to surf elsewhere, they can bookmark into the other pages (which makes sense). If they shut down IE altogether they have to login. However, I tried leaving the thing set to another page after logging in and went to lunch, but when I came back the bookmark worked. I suppose I am not doing something right.

I am doing Response.Cookies(“LoginID”) = Session.SessionID to load the variable and testing if LoginID is not blank on subsequent pages. I could do something else I suppose, like put in “LoggedOK” instead of the SessionID… This is just creating a cookie. And how do you get a cookie to die in 20 minutes/1 hour etc.? my reference book sez intervals of days.

I have been given to understand that session vars time out in 20 minutes default. How do I load a session var and then later try to read it? my reference book is a little unclear on the concept and the google searches give me a lot of forum chatter. I’m also tired today and feeling a little lazy…..

what code do you need to use to

1) load a session var with *something*
2) read the var on other pages

and where do you tell the var how long to live?

One problem is, I keep getting confused by whether this has anything to do with cookies. are session vars a *class* of cookies? If so, all I really want to know is, how to tell a cookie to die in an interval less than a day.

TIA

Reply | Quote

Okay, that’s complete overload for me right now. If you want the ASP session to die sooner, you can change the global default for your application. Check your global.asa file and pages for statements assigning a value to Session.Timeout (e.g., Session.Timeout = 60, to keep the session alive 60 minutes). Get rid of any you don’t need, then put Session.Timeout = 7 in global.asa’s Session_OnStart procedure to set a global Timeout of 7 minutes. You can tweak this as you learn what the optimal time is for normal users.

Reply | Quote

Okay, that’s complete overload for me right now. If you want the ASP session to die sooner, you can change the global default for your application. Check your global.asa file and pages for statements assigning a value to Session.Timeout (e.g., Session.Timeout = 60, to keep the session alive 60 minutes). Get rid of any you don’t need, then put Session.Timeout = 7 in global.asa’s Session_OnStart procedure to set a global Timeout of 7 minutes. You can tweak this as you learn what the optimal time is for normal users.

Reply | Quote

Sorry for the late comment, but I just stumbled across a resource that will undoubtedly answer most of your questions about ASP User Authentication:

4GuysFromRolla – User Authentication

Reply | Quote

interesting. i am toying with the idea of wrapping my setup with Global.asa so I can control session timeouts with some precision. Actually, for the app I am working on I’m not terribly worried about the security issue as the webpage is only going to be announced to a set group of people on the intranet and they are given passwords/UIDs at the discretion of division managers. in other words, 1) the pages to be protected are not available to the public and 2) the pages to be protected will not be announced agency-wide but only to those with a ‘need to know’ basis. In practice, the security issue is simply this:

someone from another part of the agency manages to stumble upon the login and has (for some reason) the uid and absurd password we have devised. They may then be able to login to the system. OR, more likely, an approved user logs in, then leaves the site without ever shutting down the browser. They’ve also bookmarked pages behidn the login screen. Some unapproved person can go to their pooter and ‘drop in’ to the system via the bookmark. None of these scenarios is terribly likely.

Basically, I need to set a timeout on the session that is a little more meaningful than what’s there now just to ensure that those who login don’t keep logged in perpetually. I think that should suffice. If there’s a way to PREVENT pages from being bookmarked, that’d be real good as well.

My main puzzle in the whole question of authenticating is: how to pass a value from one page to another in the most inaccessible way to the average user? Obviously, passing a flag value in a form POST is a bit dumb; using is snoopable; Session Vars/cookies seems a better solution to the issue of passing a flag from the login page to other pages. The idea is, if you don’t hit the login page, the var never loads and is empty when checking. Of course, the problem is if you login once successfully you can jump into the other pages without logging in — unless the var times out. If I can set the timeout without using Global.asa that appeals to my great laziness but I’m not that scared of Global.asa and might as well learn more about it.

SO, Global.asa is (apparently) the way to go for managing session.timeout. There may be some javascript for disabling the bookmark function but I haven’t run across anything yet in the course of my googlage.

The other thing I am more concerned about is the SQL Injection hack, as I have a large and rather complex system that is open to the public and I’ll need to investigate how to control for SQL Injection attacks. One thing to do immediately is to implement replace(‘, ”) on all “free” textboxes, but I believe I’ve already done that. At least, I have to anyway to prevent UPDATE from bombing. Optionally (and this is what I am most interested in at the moment) I need to check the level of permission the connect string gives to make sure some kind of munged SQL string doesn’t give interesting access to the db. I need a connection that allows R/W to tables, executing Stored Procs and create and delete of TEMP tables. I believe the current privledges of the connect script give dbo access to the server.

Reply | Quote

One way to make bookmarks less than useful is to insert a session identifier (tied in some manner to the ASP session identifier) into the URL as the first parameter. Users are unlikely to edit the URL they are bookmarking, and your application will detect that the URL does not match the ASP session identifier and therefore is invalid. Again, this requires that the session time out before the interloper happens upon the browser and finds the bookmark.

Regarding SQL injection, after some testing of my application, I added this code to cleanse the relevant input. Fortunately, I only have one field to worry about!

Dim strUserInput
strUserInput = Trim(Request("FieldName"))
If InStr(1, strUserInput, ";") > 0 Then
	strUserInput = Left(strUserInput, InStr(1, strUserInput, ";") - 1)
End If
If InStr(1, strUserInput, "--") > 0 Then
	strUserInput = Left(strUserInput, InStr(1, strUserInput, "--") - 1)
End If
If InStr(1, strUserInput, "'") > 0 Then
	strUserInput = Left(strUserInput, InStr(1, strUserInput, "'") - 1)
End If

All that does is truncate additional SQL commands ( ; delimiter), attempts to truncate queries ( — comments delimiter) and attempts to use OR conditions (following a close literal delimiter). There may be other ways to sneak past, but most should simply returns zero records, which is an event my code can handle without any changes.

Reply | Quote

One way to make bookmarks less than useful is to insert a session identifier (tied in some manner to the ASP session identifier) into the URL as the first parameter. Users are unlikely to edit the URL they are bookmarking, and your application will detect that the URL does not match the ASP session identifier and therefore is invalid. Again, this requires that the session time out before the interloper happens upon the browser and finds the bookmark.

Regarding SQL injection, after some testing of my application, I added this code to cleanse the relevant input. Fortunately, I only have one field to worry about!

Dim strUserInput
strUserInput = Trim(Request("FieldName"))
If InStr(1, strUserInput, ";") > 0 Then
	strUserInput = Left(strUserInput, InStr(1, strUserInput, ";") - 1)
End If
If InStr(1, strUserInput, "--") > 0 Then
	strUserInput = Left(strUserInput, InStr(1, strUserInput, "--") - 1)
End If
If InStr(1, strUserInput, "'") > 0 Then
	strUserInput = Left(strUserInput, InStr(1, strUserInput, "'") - 1)
End If

All that does is truncate additional SQL commands ( ; delimiter), attempts to truncate queries ( — comments delimiter) and attempts to use OR conditions (following a close literal delimiter). There may be other ways to sneak past, but most should simply returns zero records, which is an event my code can handle without any changes.

Reply | Quote

Your use of the Global.asa sounds like a good plan.

I would recommend that if you use hidden form fields or persistent cookies that you encrypt any sensitive values. You should be able to find a free encryption ASP component pretty easily. This will turn something like userid=”bob” into userid=”HTb6bD5UqdPz4kvve1HltA==”. This will help prevent anyone from easily breaking into your application since they won’t have the encryption algorithm or the encryption key.

Regarding SQL injection attacks, Jefferson’s code snippet can go a long way to keeping unwanted attacks from happening. But one of the best ways to eliminate this possibility is by using Stored Procedures for ALL calls to your database. That may seem drastic in the Classic ASP world, but it is totally possible and not much more difficult than building dynamic SQL statements. Additionally, this technique is even easier to implement in the .NET world.

The benefits of using Stored Procedures for everything (Select, Update, Insert, Delete – even dynamic Selecting) is that you can isolate the permissions for that particular account to ONLY the necessary Stored Procedures. You can totally remove ALL permissions for all Tables, Views, and un-needed Stored Procedures. Grant your web user account only execute permissions to the Stored Procedures needed for your application. All values you need to pass in can be done via parameters. When I started coding this way I found a slight learning curve for dealing with certain situations in T-SQL, but the security benefits far outweighed the cost in learning time.

Just to illustrate my point (I hope it’s OK to post a relatively common hack here)… A hacker can insert a few simple characters into a textbox to trick a dynamically generated SQL statement into returning TRUE. Suppose that you were building the following SQL statement to check for a username and password combination to allow a user into your site:
“SELECT Count(*) FROM Users WHERE UserName='” & txtUser.Text & “‘ AND Password='” & txtPassword.Text & “‘”

All a hacker would have to do to trick this statement in to returning true is place the following characters into the Password field: ‘ OR 1=1 —

The first single quote closes the password string. The OR 1=1 adds logic to the select statement that will force it to return true, and the — tells SQL Server to ignore any SQL code after that. So in essence you would have the following SQL Statement: SELECT COUNT(*) FROM Users WHERE Username=’YourUsername’ AND Password=” OR 1=1 –….

Anyway, you can read more about that here.

The bottom line is that using Stored Procedures with Parameters will eliminate this possible vulnerability since any characters in the Parameter will be taken literally and not included as part of the SQL Statement.

Sorry for the long post, but security is very serious stuff!

Reply | Quote

I agree on the stored procedures. In the above application, I don’t have the option to change the database, but I do use them where I can (even in MDB files where we still call them queries ).

Reply | Quote

I agree on the stored procedures. In the above application, I don’t have the option to change the database, but I do use them where I can (even in MDB files where we still call them queries ).

Reply | Quote

ok then Global.asa it is!

I’m definately interested in going to Stored Procs on all recordset stuff but am a long way from doing that as of yet. one of my problems with Stored Procs and ASP is how to output the results to a webpage. This is not so hard when I know the SP is going to return one column ((0) in the ASP recordset) but if I need to do more than that and want names and not array indexes (which I WILL) I need to learn a lot more. My focus on SPs is to get better performance, but I’m aware of the permissions/security in SPs & I’d suppose that will be help circumvent SQL Injection hackage. Another thing to check on is the level of security I’m giving people in the connect string to begin with.

As far as general strategies for guarding against SQL Injection, most of my pages hit the db when the user attempts to send a largish amount of form data to the db. This involves the construction of a (more or less complex) UPDATE statement; in my experience a malformed SQL String using UPDATE doesn’t gives you anything informative. Also, my SQL for checking the login is not SELECT COUNT(*) but SELECT * FROM

WHERE . One simple suggestion here is to put in some filters to reject strings in both areas that don’t fit expected input for the UID and password. this is easy to do because we are (at the moment) generating the UID/password. the people can’t just make up one. I’m recommending that we go that route at some point; at which point I’ll have to put in checks against certain types of UID/passwords.

I like to not limit people’s ability to enter whatever they want in a textbox so just do the check and replace for apostrophes at the backend when the UPDATE string is being composed. I can think of many reasons people might want to use ‘, — or ; on a regualar form.

well I could blather some more (don’t feel like working!) but I won’t impose…

Reply | Quote

Reading a recordset from a Stored Procedure is very simple:

Set yourRecordset = yourCommandObject.Execute()

Then you have a standard recordset to work with… See Microsoft’s documentation on the Execute Method

I wouldn’t suggest that you prevent users from entering any text they want in ALL fields, but definitely in fields where those characters will NEVER exist (username/password). That means you’ll need to put some restrictions on characters allowed in a password field.

It is also a good idea to not echo text directly to a page without using the Server.HTMLEncode() method. That will help prevent all kinds of display issues and Cross-Site Scripting attacks. Never (NEVER) trust user input – even for internal users!

Reply | Quote

OK, I’ll look into the SQL Stuff eventually. the people here have not committed to the job they offered me (that is, they don’t know if they can PAY me for the position they put together) so my days in High Tech here may be drying up eventually.

Time to polish up the resume!

As far as my original question re. password security, I may just simply put in some javascript validation to block unusual data (since I know the max length of the login and it’s all alpha and know the precise format of the password this should be easy). One thing I also did, which in hindsight seems actually clever is I set all the password check stuff on a simple Access db that has nothing to do with the data in the main (protected) site so even if someone does try to hack they’ll get a very boring profile of a very boring db. The protected page in question is a search page and there it is not easy to control for input as people are looking for records based on a name (could be anything) of a type of ID (also varies unpredicatably). But, like I said, the whole project will not be publically accessible and the people in the agency who can see it are limited, so there’s already some “institutional” security built-in.

Reply | Quote

You probably won’t have any problems with using Javascript to help with validation since your users are all internal. However, in external applications a hacker could very easily bypass the javascript and send undesired characters back to the server. Be sure to run similar validation routines on the server (in the ASP code) in addition to any you run on the client (with Javascript code).

Reply | Quote

well I don’t know if it’s foolproof, but all my public pages require javascript. if you have it turned off

I won’t play with you!

I haven’t been in the habit of using VBscript to validate form stuff. I’ve gotten used to Javascript’s way of doing stuff on the DOM. (Not that I enjoyed the experience — still get cold sweats some nights from the effort.) I’ve developed quite a suite of validation code in a handy validate.js include file that does a lot of the heavy lifting on the client side. If there’s away to bypass return false; all of that effort gets hosed. please don’t tell me there’s some trick out there that all 12 years olds know about!!

Not sure how to implement validation ‘on the server side’ unless you mean posting a form to itself.

Reply | Quote

Your technique is a great start.

Here’s the problem… If a hacker (let’s call him/her “Pat”) wants to bypass your Javascript validation here’s how Pat can do it:
– Navigate to the desired page on your site (presumably having logged in and met any authorization criteria you have established)
– Save the page as a .HTM file on Pat’s local hard drive
– Edit the HTM page, removing the nifty Javascript validation you’ve created, allowing any desired characters to be entered
– Change the action value of your tag to an absolute URL rather than a relative URL (or page name)
– Save the HTM page
– Open the HTM page locally in a browser
– Enter bad data
– Submit the form

Your site will receive the form just as if it were submitted normally. The best case is that you may receive some invalid data (such as a numeric value above or below the desired limit); worst case, you could expose yourself to a SQL injection attack and have your whole database in jeopardy. Pat’s a smart 12 year old!

Server-side validation is simple: On the page that processes the form input (not necessarily the same page that submitted it, but that’s one way to do it), include functionality to perform any necessary checks before saving or updating the submitted data. Run a check on every single form element that you’re processing to make sure it meets the desired requirements (length, data type, etc). If it fails any of the tests (presumably because of bad input or worse), take the necessary action to correct the situation. You could display the same form with the appropriate instructions to the user for correction – this would be the easiest approach if you submit the page back to itself. You could also display a simple error page with some kind of Pat-friendly error message.

It is a good practice to ALWAYS include server-side validation in addition to any optional client-side validation. Think of client-side validation as a convenience to the user (much like locking your car doors) – it helps to keep honest people honest. Think of server-side validation as a necessary security measure (like an armed guard at a bank) – it prevents malicious people from succeeding in an attack.

Reply | Quote

While Pat will be hard pressed to use that technique with an ASP application, unless Pat can do so within the timeout and your application is insensitive to referrer (!), there are hacker proxies that let you intercept an outgoing transmission, change it in any way, and then release it. I played with one of those in a security course, and I’ve heard of others. They’re rather crude, and of course, it would be extremely dangerous to one’s job to use it inside the company, but the bottom line is, as I think Mark has said, never trust user data.

Reply | Quote

While Pat will be hard pressed to use that technique with an ASP application, unless Pat can do so within the timeout and your application is insensitive to referrer (!), there are hacker proxies that let you intercept an outgoing transmission, change it in any way, and then release it. I played with one of those in a security course, and I’ve heard of others. They’re rather crude, and of course, it would be extremely dangerous to one’s job to use it inside the company, but the bottom line is, as I think Mark has said, never trust user data.

Reply | Quote

Your technique is a great start.

Here’s the problem… If a hacker (let’s call him/her “Pat”) wants to bypass your Javascript validation here’s how Pat can do it:
– Navigate to the desired page on your site (presumably having logged in and met any authorization criteria you have established)
– Save the page as a .HTM file on Pat’s local hard drive
– Edit the HTM page, removing the nifty Javascript validation you’ve created, allowing any desired characters to be entered
– Change the action value of your tag to an absolute URL rather than a relative URL (or page name)
– Save the HTM page
– Open the HTM page locally in a browser
– Enter bad data
– Submit the form

Your site will receive the form just as if it were submitted normally. The best case is that you may receive some invalid data (such as a numeric value above or below the desired limit); worst case, you could expose yourself to a SQL injection attack and have your whole database in jeopardy. Pat’s a smart 12 year old!

Server-side validation is simple: On the page that processes the form input (not necessarily the same page that submitted it, but that’s one way to do it), include functionality to perform any necessary checks before saving or updating the submitted data. Run a check on every single form element that you’re processing to make sure it meets the desired requirements (length, data type, etc). If it fails any of the tests (presumably because of bad input or worse), take the necessary action to correct the situation. You could display the same form with the appropriate instructions to the user for correction – this would be the easiest approach if you submit the page back to itself. You could also display a simple error page with some kind of Pat-friendly error message.

It is a good practice to ALWAYS include server-side validation in addition to any optional client-side validation. Think of client-side validation as a convenience to the user (much like locking your car doors) – it helps to keep honest people honest. Think of server-side validation as a necessary security measure (like an armed guard at a bank) – it prevents malicious people from succeeding in an attack.

Reply | Quote

well I don’t know if it’s foolproof, but all my public pages require javascript. if you have it turned off

I won’t play with you!

I haven’t been in the habit of using VBscript to validate form stuff. I’ve gotten used to Javascript’s way of doing stuff on the DOM. (Not that I enjoyed the experience — still get cold sweats some nights from the effort.) I’ve developed quite a suite of validation code in a handy validate.js include file that does a lot of the heavy lifting on the client side. If there’s away to bypass return false; all of that effort gets hosed. please don’t tell me there’s some trick out there that all 12 years olds know about!!

Not sure how to implement validation ‘on the server side’ unless you mean posting a form to itself.

Reply | Quote

You probably won’t have any problems with using Javascript to help with validation since your users are all internal. However, in external applications a hacker could very easily bypass the javascript and send undesired characters back to the server. Be sure to run similar validation routines on the server (in the ASP code) in addition to any you run on the client (with Javascript code).

Reply | Quote

OK, I’ll look into the SQL Stuff eventually. the people here have not committed to the job they offered me (that is, they don’t know if they can PAY me for the position they put together) so my days in High Tech here may be drying up eventually.

Time to polish up the resume!

As far as my original question re. password security, I may just simply put in some javascript validation to block unusual data (since I know the max length of the login and it’s all alpha and know the precise format of the password this should be easy). One thing I also did, which in hindsight seems actually clever is I set all the password check stuff on a simple Access db that has nothing to do with the data in the main (protected) site so even if someone does try to hack they’ll get a very boring profile of a very boring db. The protected page in question is a search page and there it is not easy to control for input as people are looking for records based on a name (could be anything) of a type of ID (also varies unpredicatably). But, like I said, the whole project will not be publically accessible and the people in the agency who can see it are limited, so there’s already some “institutional” security built-in.

Reply | Quote

Reading a recordset from a Stored Procedure is very simple:

Set yourRecordset = yourCommandObject.Execute()

Then you have a standard recordset to work with… See Microsoft’s documentation on the Execute Method

I wouldn’t suggest that you prevent users from entering any text they want in ALL fields, but definitely in fields where those characters will NEVER exist (username/password). That means you’ll need to put some restrictions on characters allowed in a password field.

It is also a good idea to not echo text directly to a page without using the Server.HTMLEncode() method. That will help prevent all kinds of display issues and Cross-Site Scripting attacks. Never (NEVER) trust user input – even for internal users!

Reply | Quote

ok then Global.asa it is!

I’m definately interested in going to Stored Procs on all recordset stuff but am a long way from doing that as of yet. one of my problems with Stored Procs and ASP is how to output the results to a webpage. This is not so hard when I know the SP is going to return one column ((0) in the ASP recordset) but if I need to do more than that and want names and not array indexes (which I WILL) I need to learn a lot more. My focus on SPs is to get better performance, but I’m aware of the permissions/security in SPs & I’d suppose that will be help circumvent SQL Injection hackage. Another thing to check on is the level of security I’m giving people in the connect string to begin with.

As far as general strategies for guarding against SQL Injection, most of my pages hit the db when the user attempts to send a largish amount of form data to the db. This involves the construction of a (more or less complex) UPDATE statement; in my experience a malformed SQL String using UPDATE doesn’t gives you anything informative. Also, my SQL for checking the login is not SELECT COUNT(*) but SELECT * FROM

WHERE . One simple suggestion here is to put in some filters to reject strings in both areas that don’t fit expected input for the UID and password. this is easy to do because we are (at the moment) generating the UID/password. the people can’t just make up one. I’m recommending that we go that route at some point; at which point I’ll have to put in checks against certain types of UID/passwords.

I like to not limit people’s ability to enter whatever they want in a textbox so just do the check and replace for apostrophes at the backend when the UPDATE string is being composed. I can think of many reasons people might want to use ‘, — or ; on a regualar form.

well I could blather some more (don’t feel like working!) but I won’t impose…

Reply | Quote

Your use of the Global.asa sounds like a good plan.

I would recommend that if you use hidden form fields or persistent cookies that you encrypt any sensitive values. You should be able to find a free encryption ASP component pretty easily. This will turn something like userid=”bob” into userid=”HTb6bD5UqdPz4kvve1HltA==”. This will help prevent anyone from easily breaking into your application since they won’t have the encryption algorithm or the encryption key.

Regarding SQL injection attacks, Jefferson’s code snippet can go a long way to keeping unwanted attacks from happening. But one of the best ways to eliminate this possibility is by using Stored Procedures for ALL calls to your database. That may seem drastic in the Classic ASP world, but it is totally possible and not much more difficult than building dynamic SQL statements. Additionally, this technique is even easier to implement in the .NET world.

The benefits of using Stored Procedures for everything (Select, Update, Insert, Delete – even dynamic Selecting) is that you can isolate the permissions for that particular account to ONLY the necessary Stored Procedures. You can totally remove ALL permissions for all Tables, Views, and un-needed Stored Procedures. Grant your web user account only execute permissions to the Stored Procedures needed for your application. All values you need to pass in can be done via parameters. When I started coding this way I found a slight learning curve for dealing with certain situations in T-SQL, but the security benefits far outweighed the cost in learning time.

Just to illustrate my point (I hope it’s OK to post a relatively common hack here)… A hacker can insert a few simple characters into a textbox to trick a dynamically generated SQL statement into returning TRUE. Suppose that you were building the following SQL statement to check for a username and password combination to allow a user into your site:
“SELECT Count(*) FROM Users WHERE UserName='” & txtUser.Text & “‘ AND Password='” & txtPassword.Text & “‘”

All a hacker would have to do to trick this statement in to returning true is place the following characters into the Password field: ‘ OR 1=1 —

The first single quote closes the password string. The OR 1=1 adds logic to the select statement that will force it to return true, and the — tells SQL Server to ignore any SQL code after that. So in essence you would have the following SQL Statement: SELECT COUNT(*) FROM Users WHERE Username=’YourUsername’ AND Password=” OR 1=1 –….

Anyway, you can read more about that here.

The bottom line is that using Stored Procedures with Parameters will eliminate this possible vulnerability since any characters in the Parameter will be taken literally and not included as part of the SQL Statement.

Sorry for the long post, but security is very serious stuff!

Reply | Quote

interesting. i am toying with the idea of wrapping my setup with Global.asa so I can control session timeouts with some precision. Actually, for the app I am working on I’m not terribly worried about the security issue as the webpage is only going to be announced to a set group of people on the intranet and they are given passwords/UIDs at the discretion of division managers. in other words, 1) the pages to be protected are not available to the public and 2) the pages to be protected will not be announced agency-wide but only to those with a ‘need to know’ basis. In practice, the security issue is simply this:

someone from another part of the agency manages to stumble upon the login and has (for some reason) the uid and absurd password we have devised. They may then be able to login to the system. OR, more likely, an approved user logs in, then leaves the site without ever shutting down the browser. They’ve also bookmarked pages behidn the login screen. Some unapproved person can go to their pooter and ‘drop in’ to the system via the bookmark. None of these scenarios is terribly likely.

Basically, I need to set a timeout on the session that is a little more meaningful than what’s there now just to ensure that those who login don’t keep logged in perpetually. I think that should suffice. If there’s a way to PREVENT pages from being bookmarked, that’d be real good as well.

My main puzzle in the whole question of authenticating is: how to pass a value from one page to another in the most inaccessible way to the average user? Obviously, passing a flag value in a form POST is a bit dumb; using is snoopable; Session Vars/cookies seems a better solution to the issue of passing a flag from the login page to other pages. The idea is, if you don’t hit the login page, the var never loads and is empty when checking. Of course, the problem is if you login once successfully you can jump into the other pages without logging in — unless the var times out. If I can set the timeout without using Global.asa that appeals to my great laziness but I’m not that scared of Global.asa and might as well learn more about it.

SO, Global.asa is (apparently) the way to go for managing session.timeout. There may be some javascript for disabling the bookmark function but I haven’t run across anything yet in the course of my googlage.

The other thing I am more concerned about is the SQL Injection hack, as I have a large and rather complex system that is open to the public and I’ll need to investigate how to control for SQL Injection attacks. One thing to do immediately is to implement replace(‘, ”) on all “free” textboxes, but I believe I’ve already done that. At least, I have to anyway to prevent UPDATE from bombing. Optionally (and this is what I am most interested in at the moment) I need to check the level of permission the connect string gives to make sure some kind of munged SQL string doesn’t give interesting access to the db. I need a connection that allows R/W to tables, executing Stored Procs and create and delete of TEMP tables. I believe the current privledges of the connect script give dbo access to the server.

Reply | Quote

Sorry for the late comment, but I just stumbled across a resource that will undoubtedly answer most of your questions about ASP User Authentication:

4GuysFromRolla – User Authentication

Reply | Quote

> 1) what’s a good way to send data from page to page without it being visible to the client? Cookies? Session Variables? Elves?

This depends on what you mean by “visible” – available to the naked eye or discoverable with a bit of effort? Anything your page sends to the user can be discovered.

The ASP session key, which is stored by the browser as a session cookie, uniquely identifies that session. But you can corroborate it with information from the HTTP headers (e.g., IP Address, UserAgent string). However, ASP doesn’t run without it, so you do have to send that back and forth to use ASP (note: this is automatic). For other information, if it is sensitive, it does make sense to store it on the server. If you don’t like session variables, how about a database?

> 2) how to ensure that the user (ideally) can never ‘leave’ the system and come back behind the login via a bookmark?
> is there a xbrowser block bookmarks script that is available? Any other ideas on what might be an issue with ensuring
> that people have, indeed, logged in? Flags to a db perhaps?

One possibility is to check the HTTP_Referer property in your ASP page. This will be blank for bookmarks, unless the user intentionally fills in deceptive information. If the property shows an address on your server, it is likely that the person is navigating normally. If there is an address from somewhere else in cyberspace, you have something interesting to investigate.

Using JavaScript, you can inspect some information about the History object. Maybe if the immediately previous page in the History is not from your server, you could clear the page or refresh to the login screen? This wouldn’t prevent someone from using back to see pages they saw before, unless the browser failed to cache them in the first place. I haven’t looked into it, but I suspect that there are ways to both limit caching and detect refreshing.

Have fun!

Reply | Quote