ASP Security

[GingerNinja]

I am trying to prevent users from submitting HTML pages from their
local machine to our website and I was wondering what the best way of
doing this was.

I was thinking about using the HTTP_REFERER server variable (to check
where the user has submitted a page from) as a blanket fix however
when you use the javascript document.location on a page the
HTTP_REFERER is always blank, which makes that a flawed fix.

I have seen other sites protect against this, so I know it can be
done. Whats the best way.

Thanks for listening.

[Dave Anderson]

GingerNinja wrote:

I am trying to prevent users from submitting HTML pages from their
local machine to our website and I was wondering what the best way of
doing this was.

I was thinking about using the HTTP_REFERER server variable (to check
where the user has submitted a page from) as a blanket fix however
when you use the javascript document.location on a page the
HTTP_REFERER is always blank, which makes that a flawed fix.

I have seen other sites protect against this, so I know it can be
done. Whats the best way.

There is no such thing as client-side security.

You can't even guarantee that HTTP_REFERER isn't spoofed. With Mozilla
FireFox, I can already edit my headers and re-send the request (I can also
"unhide" your hidden inputs and change their values while I'm at it). How
would your ability to sense HTTP_REFERER help you in any way.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

[Steven Burn]

Try this (pseudo code)

<%
strTemp = Request.Servervariables("SERVER_NAME")
if Not request.servervariables("HTTP_REFERER")=strTemp Then
Response.Write "Woops, your not supposed to be doing this, now go
away"
else
Response.Write "Thats the way to do it"
end if
%>

--

Regards

Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk

Keeping it FREE!
"GingerNinja" <gr*******@hotmail.com> wrote in message
news:71**************************@posting.google.c om...

I am trying to prevent users from submitting HTML pages from their
local machine to our website and I was wondering what the best way of
doing this was.

I was thinking about using the HTTP_REFERER server variable (to check
where the user has submitted a page from) as a blanket fix however
when you use the javascript document.location on a page the
HTTP_REFERER is always blank, which makes that a flawed fix.

I have seen other sites protect against this, so I know it can be
done. Whats the best way.

Thanks for listening.

[Bullschmidt]

Here's a sample piece of code that might give some ideas and provide at
least some security:

' If there's a referer (such as from a form post), be sure it's from
this site.
If Request.ServerVariables("HTTP_REFERER") <> "" Then
' If this pg opened with SSL.
If Request.ServerVariables("HTTPS") = "on" Then
If jpsvbPartOfURL(Request.ServerVariables("HTTP_REFER ER"), "host") <>
mstrSiteHostSecure Then
Response.Redirect mstrSiteMainSecure & "/login.asp"
End If
Else
If jpsvbPartOfURL(Request.ServerVariables("HTTP_REFER ER"), "host") <>
mstrSiteHost Then
Response.Redirect mstrSiteMainSecure & "/login.asp"
End If
End If
End If

Best regards,
J. Paul Schmidt, Freelance ASP Web Designer
http://www.Bullschmidt.com
ASP Designer Tips, ASP Web Database Demo, Free ASP Bar Chart Tool...
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

[GingerNinja]

> How would your ability to sense HTTP_REFERER help you in any way.

On a basic level HTTP_REFERER would allow the ASP script to detect
where the HTML page was posted from, you could check the domain. If it
were posted from a HTML page on someones PC there would be no
HTTP_REFERER, unless ofcouse you spoof it. Like I said its a flawed
method. WHICH IS WHY I ASKED FOR HELP!

[GingerNinja]

Thanks for the response, that solution would work a treat.
Unfortunitely if you use javascript to redirect to a page i.e.
document.location = 'mypage.asp' there doesnt seem to be a
HTTP_REFERER, so it would think that a legit page is infact an access
volilation and kick them out in error. Its probably design intent, but
a pain none the same. I'll have to get rid of all the
document.location's unfortunitely I have inherited the original code
and I cant be certain that I'll catch all the document.locations,
guess I'll have to trust a find and replace eh? :-P

Cheers again

Try this (pseudo code)

<%
strTemp = Request.Servervariables("SERVER_NAME")
if Not request.servervariables("HTTP_REFERER")=strTemp Then
Response.Write "Woops, your not supposed to be doing this, now go
away"
else
Response.Write "Thats the way to do it"
end if
%>

--

Regards

Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk

[Dave Anderson]

GingerNinja wrote:

On a basic level HTTP_REFERER would allow the ASP script to detect
where the HTML page was posted from, you could check the domain. If it
were posted from a HTML page on someones PC there would be no
HTTP_REFERER, unless ofcouse you spoof it. Like I said its a flawed
method. WHICH IS WHY I ASKED FOR HELP!

My point is that, while HTTP_REFERER can be useful, you should try to avoid
depending on it for your application to function.

And your application *security* should never depend on it. If you have
something worth protecting, that is.

What should you use? SSL, for one thing. I know it's expensive, but anything
worthwhile usually is. Besides, you probably don't need to use SSL for the
entire application.

Amazon represents a decent model for web applications that mix secure and
non-secure segments. Most of what you do on their site requires no security.
You get to queue up a transaction -- and quite possibly an enormous one --
while your identity has not been confirmed (and might be entirely unknown),
then commit to it only after logging in through the secure server.

While you are using Amazon's site, your session is tracked, whether you have
logged in or not. That session spans their entire server farm, and in some
circumstances can even be resumed from another computer/browser session.

Do yourself a favor, and trace a visit to Amazon**. Put something in your
shopping cart and proceed to checkout (no need to actually check out). Look
at the progression of redirections and cookies in the process. Consider what
Amazon gets from each request and how that maps to WHAT AMAZON KNOWS. For
example, I typed in http://amazon.com/ and this was what my browser sent
(cleaned up for display and privacy):

GET http://amazon.com/ HTTP/1.1
Host: amazon.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9
Accept: text/xml,application/xml,application/xhtml+xml,text/html;
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: x-main=X6u4uuCVtnpcgyxVkjY4DkoHxqK01gzx;
session-id-time=1095667200;
ubid-main=430-2712009-5438522;
session-id=102-3281207-0584588;
order_cache_primed=1A3DQZB9MCKXADJ;
obidos_path_continue-shopping=continue-shopping-url=
/subst/home/home.html/102-3281207-0584588&
continue-shopping-post-data=
&continue-shopping-description=generic.gateway.default

Not much in there about me, right? But it did greet me with "Hello, Dave
Anderson", and there was even an item in my shopping cart from a session I
initiated at a different computer several days ago. Interestingly, each
browser has a unique cookie signature, and each of MY combinations of
cookies maps to the same common "session".

At this point, you're probably wondering what this has to do with security.
Well, it has *everything* to do with security. Amazon understands that a
request is just a bundle of unverified stuff thrown at its servers. It knows
not to trust most of the information in the request -- and that includes
HTTP_REFERER. I would venture a guess that Amazon trusts nothing whatsoever
in this request.

The site uses a token to track the session. It only puts the token into a
relationship of trust when I log in through the SSL segment. Everything
leading up to that point is a staging step. Nothing important happens out
there.

In short, you should act as though the client is free to change anything he
likes in the request. If you are unable to accept that, then you should
reconsider having a web application at all.


**SUGGESTION: Use Mozilla FireFox (http://www.mozilla.org/products/firefox/)
and the LiveHTTPHeaders extension
(http://extensionroom.mozdev.org/more...ivehttpheaders) to view the
traffic. The default filter (/$|.html$) helps cut some of the noise at the
beginning, but you can't see the entire picture if you leave it on.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.