Securing your web application against dangerous request

While programming with web applications it is common to split the task to different pages. Most of the times we will have to pass parameters to other pages using query string and sometimes it is the only viable method to accomplish certain tasks.You can pass values to other pages using request objectRequest. redirect ("YourPage.aspx?list="+TextBox1.Text+"&&custid="+ TextBox2.Text) Alas this method comes with certain risks. What if someone writes a request directly in the address bar? What if someone pass values to the above list and custid variables in query string?. Could he/she be able to discover some secret information? I am afraid a skilled user can .

Block Them Outside

The basic idea is to impede those request that comes from outside our website. Do we have a server variable which gives the origin of a request? Yes it is HTTP_REFERER, which uses below syntax.Request.ServerVariables["HTTP_REFERER"].

Let's see what Microsoft has to tell about this variable.

HTTP_REFERER: Returns a string that contains the URL of the page that referred the request to the current page using an HTML tag.

Ok... That's it. This is the variable we are reckoning on. Have a close scout on this variable. When you request the page by typing the URL in the address bar, HTTP_REFERER is empty, even if you typed the whole exact URL!

Which all pages we need to protect. At the least the pages that reads the query string.

[As I mentioned before HTTP_REFERER will contain the URL of the page that referred the request to the current page if the request originated from our website otherwise the variable will be having null]

Check this code out. Place the below code in your page load event.

if (Request.ServerVariables["HTTP_REFERER"] !=null && NoofOccurence(Request.ServerVariables["HTTP_REFERER"])>0) { // Code to be run if query string is not changed } else { //Error message }

A Web application may be comfortable to build and implement thanks to smooth technologies such as ASP.Net. But do not forget that they are public; they're "by nature" exposed to attacks. Now we've learned how to block requests that aren't originated by the Web site by issuing a virtual firewall against external, not authorized, and potentially dangerous requests.

Your projects are broken, they just havn't been attacked yet=2E
The referrer is sent by the client in the HTTP header:
Referrer: Some URL
Custom clients can put any value they want in there, proxy's can=
strip them out=2E Think about all the referrer log spam you see: =
How do you think it got there?
Session cookies are spoofable (again sent by the client) but you=
can verify that you set them by taking a random value and=
assigning it to an ID=2E When the user gets to the second page=
check the random value/ID pair they sent to what you have in the=
database (that you set on the previous page) if they don't match=
then they're trying to spoof you=2E
If they can somehow guess the random/id pair they deserve to get=
in=2E

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.