Major security issue?

Discussion in 'ASP .Net' started by Keith, Feb 1, 2004.

  1. Keith

    Keith Guest

    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?
    Keith, Feb 1, 2004
    #1
    1. Advertising

  2. Keith

    Ray at Guest

    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" <> wrote in message
    news:77b301c3e87d$0ff55c00$...
    > 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?
    Ray at, Feb 1, 2004
    #2
    1. Advertising

  3. Keith

    Keith Guest

    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" <> wrote in message
    >news:77b301c3e87d$0ff55c00$...
    >> 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?

    >
    >
    >.
    >
    Keith, Feb 1, 2004
    #3
  4. Keith

    Ray at Guest

    "Keith" <> wrote in message
    news:7c0f01c3e881$00918d70$...

    > 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
    Ray at, Feb 1, 2004
    #4
  5. Keith

    Paul Glavich Guest

    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" <> wrote in message
    news:7c0f01c3e881$00918d70$...
    > 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" <> wrote in message
    > >news:77b301c3e87d$0ff55c00$...
    > >> 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?

    > >
    > >
    > >.
    > >
    Paul Glavich, Feb 1, 2004
    #5
  6. Keith

    Max Guest

    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" <> wrote in message
    news:77b301c3e87d$0ff55c00$...
    > 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?
    >
    Max, Feb 1, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kokwooi

    Major Major Problem With ASP.NET

    kokwooi, Sep 18, 2003, in forum: ASP .Net
    Replies:
    6
    Views:
    664
    NuTcAsE
    Sep 19, 2003
  2. Amir Ghezelbash

    Major Security Issue

    Amir Ghezelbash, Apr 22, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    312
    Arthur Nesterovsky
    Apr 23, 2004
  3. Jef Driesen
    Replies:
    2
    Views:
    1,689
    Jef Driesen
    Jan 12, 2006
  4. Keith

    Major ASP.Net Security Issue?

    Keith, Feb 1, 2004, in forum: ASP .Net Security
    Replies:
    2
    Views:
    132
    Paul Glavich
    Feb 1, 2004
  5. ara howard
    Replies:
    0
    Views:
    224
    ara howard
    Oct 28, 2003
Loading...

Share This Page