473,386 Members | 1,758 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,386 software developers and data experts.

Major security issue?

I have found what I believe to be a serious security
issue in ASP.Net. If you have:

1. Your website configured for anonymous access
2. Elect under web.config to set the sessionstate
attribute of cookieless to true

Anyone from any IP address or across another browser can
copy the URL and work within the session. My question
is "Why doesn't ASP.Net provide an option around ensuring
all requests for a user session originate from the same
IP address and/or same useragent?" I know that some
people sit behind firewalls, proxies and layer 4 devices
that could load balance and affect HTTP traffic, but it
honestly escapes me why I can access my web application
on any machine inside or outside of my network with just
the sessionid in the URL from even different browsers.
There must be a way to control this in the
configuration. Am I alone in find this troubling?
Nov 18 '05 #1
5 1088
It seems to me that this would be listed as a predictable downside to using
cookieless sessions. Verifying IPs and/or user agents wouldn't be any real
way to avoid this, so it makes sense to me that this wouldn't be the default
behavior for asp.net to check that. And if it were to check it, where would
it store this info? In session variables? Hmmph.

--

Ray at home
Microsoft ASP MVP
"Keith" <ke***@keithadler.com> wrote in message
news:77****************************@phx.gbl...
I have found what I believe to be a serious security
issue in ASP.Net. If you have:

1. Your website configured for anonymous access
2. Elect under web.config to set the sessionstate
attribute of cookieless to true

Anyone from any IP address or across another browser can
copy the URL and work within the session. My question
is "Why doesn't ASP.Net provide an option around ensuring
all requests for a user session originate from the same
IP address and/or same useragent?" I know that some
people sit behind firewalls, proxies and layer 4 devices
that could load balance and affect HTTP traffic, but it
honestly escapes me why I can access my web application
on any machine inside or outside of my network with just
the sessionid in the URL from even different browsers.
There must be a way to control this in the
configuration. Am I alone in find this troubling?

Nov 18 '05 #2
This is predictable in an insecure product. I'm not
trying to act as if I discovered something new or Earth
shattering, but I am quite surprised there is nothing in
place in ASP.Net to protect user sessions from being
hijacked. It seems to me that the session IDs have been
problematic since ASP first came about. In ASP.Net they
are still for some reason handed out in a fashion that
means the same ID could be sent out to the same browser
even after a Session.Abandon(). It doesn't make sense
that Microsoft couldn't do something as simple as encrypt
the user agent and source IP into the session GUID if the
user wanted to lock the source and device of a request
down to a particular computer/network. From an
architectural standpoint I realize that this in itself
would add some overhead to IIS because every HTTP request
would have to be checked against a lookup, but with HTTP
keep-alives this check would only need to occur once on
the same connection. I also realize that someone could
use this to DoS a server by sending lots of HTTP requests
with random IDs that would have to decoded and matched up
against connections, but I'm sure that intrusion
detection systems could be made to deal with this issue.
The other option of course is to not use cookieless
sessions under the anonymous user configuration and rely
on an in-memory cookie which is obviously a little less
accessible. In either situation though, this seems like
an incredible option to not provide ASP users.
-----Original Message-----
It seems to me that this would be listed as a predictable downside to usingcookieless sessions. Verifying IPs and/or user agents wouldn't be any realway to avoid this, so it makes sense to me that this wouldn't be the defaultbehavior for asp.net to check that. And if it were to check it, where wouldit store this info? In session variables? Hmmph.

--

Ray at home
Microsoft ASP MVP
"Keith" <ke***@keithadler.com> wrote in message
news:77****************************@phx.gbl...
I have found what I believe to be a serious security
issue in ASP.Net. If you have:

1. Your website configured for anonymous access
2. Elect under web.config to set the sessionstate
attribute of cookieless to true

Anyone from any IP address or across another browser can copy the URL and work within the session. My question
is "Why doesn't ASP.Net provide an option around ensuring all requests for a user session originate from the same
IP address and/or same useragent?" I know that some
people sit behind firewalls, proxies and layer 4 devices that could load balance and affect HTTP traffic, but it
honestly escapes me why I can access my web application
on any machine inside or outside of my network with just the sessionid in the URL from even different browsers.
There must be a way to control this in the
configuration. Am I alone in find this troubling?

.

Nov 18 '05 #3
"Keith" <ke***@keithadler.com> wrote in message
news:7c****************************@phx.gbl...
This is predictable in an insecure product.
I can loosen all your lugnuts with a standard crossbar wrench, too. Does
that make your car an insecure product? If you think it does, use >=3 wheel
locks on each of your wheels.

I'm not
trying to act as if I discovered something new or Earth
shattering, but I am quite surprised there is nothing in
place in ASP.Net to protect user sessions from being
hijacked.
There is, real sessions, although that is arguable as well. And this has
nothing to do with what server-side technology you choose to use.
It seems to me that the session IDs have been
problematic since ASP first came about. In ASP.Net they
are still for some reason handed out in a fashion that
means the same ID could be sent out to the same browser
even after a Session.Abandon().
Even if this happened, would it matter? It'd still be a new session.
It doesn't make sense
that Microsoft couldn't do something as simple as encrypt
the user agent and source IP into the session GUID if the
user wanted to lock the source and device of a request
down to a particular computer/network.
That data is meaningless though. When you have 1000 computers created from
the same image all sitting behind the same firewall, for example.

From an
architectural standpoint I realize that this in itself
would add some overhead to IIS because every HTTP request
would have to be checked against a lookup, but with HTTP
keep-alives this check would only need to occur once on
the same connection. I also realize that someone could
use this to DoS a server by sending lots of HTTP requests
with random IDs that would have to decoded and matched up
against connections, but I'm sure that intrusion
detection systems could be made to deal with this issue.
The other option of course is to not use cookieless
sessions under the anonymous user configuration and rely
on an in-memory cookie which is obviously a little less
accessible.
Cookieless sessions are just an alternative. If you're that worried about
them, don't use them. This is not a design flaw in ASP; this is just a
result of the technology that you're using and the way it works. If you
choose to use querystrings to identify users, it doesn't matter what kind of
server-side technology you use if you're catering to the cookie-paranoid
people.
In either situation though, this seems like
an incredible option to not provide ASP users.


I keep having flashbacks to "You are already logged into another
workstation" messages from Novell clients after your computer blue screens.
I don't know why, but I am. It's really foolish to build something into a
product that can often give false positives. What you're suggesting would
have that potential.

--

Ray at home
Microsoft ASP MVP

Nov 18 '05 #4
I replied to this on the other list, but thought I'd send it here as well.

We have used cookieless sessions and what you say is true, but we used SSL
to encrypt traffic, which as you know requires a connection to the same
client/server (ie. if connection broken, then the SSL session is invalid) so
this IP verification approach could still work but it assumes SSL, which of
course is really outside of ASP.NET's domain.

Further to this you could use client certs to verify integrity which
strictly doesn't stop people from hjacking a session (simply minimises it),
but there are just som many ways to approach this, each with positives and
negatives, that if the ASP.NET team adopted one approach, it would be
implicitly be advocating this one approach which may very well be flawed
under a number of different situations.

My 2 cents.

--
- Paul Glavich
"Keith" <ke***@keithadler.com> wrote in message
news:7c****************************@phx.gbl...
This is predictable in an insecure product. I'm not
trying to act as if I discovered something new or Earth
shattering, but I am quite surprised there is nothing in
place in ASP.Net to protect user sessions from being
hijacked. It seems to me that the session IDs have been
problematic since ASP first came about. In ASP.Net they
are still for some reason handed out in a fashion that
means the same ID could be sent out to the same browser
even after a Session.Abandon(). It doesn't make sense
that Microsoft couldn't do something as simple as encrypt
the user agent and source IP into the session GUID if the
user wanted to lock the source and device of a request
down to a particular computer/network. From an
architectural standpoint I realize that this in itself
would add some overhead to IIS because every HTTP request
would have to be checked against a lookup, but with HTTP
keep-alives this check would only need to occur once on
the same connection. I also realize that someone could
use this to DoS a server by sending lots of HTTP requests
with random IDs that would have to decoded and matched up
against connections, but I'm sure that intrusion
detection systems could be made to deal with this issue.
The other option of course is to not use cookieless
sessions under the anonymous user configuration and rely
on an in-memory cookie which is obviously a little less
accessible. In either situation though, this seems like
an incredible option to not provide ASP users.
-----Original Message-----
It seems to me that this would be listed as a

predictable downside to using
cookieless sessions. Verifying IPs and/or user agents

wouldn't be any real
way to avoid this, so it makes sense to me that this

wouldn't be the default
behavior for asp.net to check that. And if it were to

check it, where would
it store this info? In session variables? Hmmph.

--

Ray at home
Microsoft ASP MVP
"Keith" <ke***@keithadler.com> wrote in message
news:77****************************@phx.gbl...
I have found what I believe to be a serious security
issue in ASP.Net. If you have:

1. Your website configured for anonymous access
2. Elect under web.config to set the sessionstate
attribute of cookieless to true

Anyone from any IP address or across another browser can copy the URL and work within the session. My question
is "Why doesn't ASP.Net provide an option around ensuring all requests for a user session originate from the same
IP address and/or same useragent?" I know that some
people sit behind firewalls, proxies and layer 4 devices that could load balance and affect HTTP traffic, but it
honestly escapes me why I can access my web application
on any machine inside or outside of my network with just the sessionid in the URL from even different browsers.
There must be a way to control this in the
configuration. Am I alone in find this troubling?

.

Nov 18 '05 #5
Max
Yes, for testing purposes I've created a 10 line VB.NET program that simply
loops thru until it enters another user's session. It does work on a lot of
ASP.NET web sites that use cookieless sessions, but it's rather random and
you don't necessarily hit any confidential data. I'm not really sure what
the implications are. In any case, I don't use cookieless sessions for
authentication. lol!

-Max
"Keith" <ke***@keithadler.com> wrote in message
news:77****************************@phx.gbl...
I have found what I believe to be a serious security
issue in ASP.Net. If you have:

1. Your website configured for anonymous access
2. Elect under web.config to set the sessionstate
attribute of cookieless to true

Anyone from any IP address or across another browser can
copy the URL and work within the session. My question
is "Why doesn't ASP.Net provide an option around ensuring
all requests for a user session originate from the same
IP address and/or same useragent?" I know that some
people sit behind firewalls, proxies and layer 4 devices
that could load balance and affect HTTP traffic, but it
honestly escapes me why I can access my web application
on any machine inside or outside of my network with just
the sessionid in the URL from even different browsers.
There must be a way to control this in the
configuration. Am I alone in find this troubling?

Nov 18 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

28
by: grahamd | last post by:
Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists.
11
by: TC | last post by:
Hello All, I have recently had the pleasure of installing Norton Internet Security 2005 and finding that I can no longer create or open a web-based application in Visual Studio .Net. The IDE...
188
by: christopher diggins | last post by:
I have posted a C# critique at http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up the following issues : - unsafe code - attributes - garbage collection -...
5
by: Ken Cox [Microsoft MVP] | last post by:
MS has posted this here: http://www.asp.net/faq/ms03-32-issue.aspx Fix for: 'Server Application Unavailable' Error after Applying Security Update for IE...
4
by: Amir Ghezelbash | last post by:
Hi every one I have a major MAJOR MAJOR problem Ok I have been using cookies for my site for a while and now I have been trying to use session less cookies because I find them much faster Any...
9
by: Tim Frawley | last post by:
I have converted a VB6 application to VB.NET. The old application made extensive use of the Clipboard for copying an Image Name so that it could be pasted into the image capture app when the user...
2
by: Jef Driesen | last post by:
I'm working on a project where i need to exchange multidimensional data between C/C++ (row-major) and matlab (column-major). I understand the difference between those two mappings to linear memory....
10
by: Richard MSL | last post by:
I am having problems working with .net security. I have been attempting to use the Microsoft .Net Framework 2.0 Configuration tool (version 2.0.50727.42), but it won't work for me. I have a simple...
1
by: WebServiceSecurity | last post by:
The issue involves the following technologies: - 1. .NET 2.0 Framework 2. WSE2.0 (WS-Security) 3. X.509 certificates 4. BEA Weblogic 8.1.5
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.