Unfortunately, using client IP in access controls/sessions will render your service unusable for some people behind load balanced proxies. In such environment the source IP is not tied to the user, and will change every now and then between a set of different IP's (not to mention that there may be thousands of other users using the same IP). Also, please note that the class of attacks described here uses the users own browser, so your IP check won't do any good here as the attacks comes from the users own browser with his IP. Further, if you pass around the ticket in URLs then this class of attacks will also have full access to the ticket from the referer URL, so if you only base your security on these two measurements (client IP + ticket present in the URL) then your are most likely at risk here. Using a one-time ticket embedded in forms (not URL's) as key to enable actions, submitted only via POST (not GET), combined with proper protection from the cross-site-scripting family of vulnerabilities should render the service quite secure against these classes of vulnerabilities, assuming there is no cross-site vulnerabilities in the browsers used. In most applications only actions needs to be protected with tickets, not information retrieval. In such cases, the ticket should be created when the user initiates an action, and only be valid for that specific action. Lets take a discussion forum as an example. There the ticket should be created when the user selects to create a message or reply. This ticket then enables the user to submit this message to the forum. While the user is only browsing the discussion forum there should not exists any ticket. To be friendly to your users a limited set of tickets should be allowed to be active (i.e. more than one but less than many). How many depends on how many actions (composing messages or whatever) you allow the user to perform in parallel. Regarding the discussion on Referer checks. These are quite weak and won't necessarily gain you anything in terms of security. It is well known that Referer can be forged, and to further add to this some browsers preserve Referer when following redirects, allowing this kind of attacks to bypass any Referer check if your users follows URL's (direct or indirect via images) posted by other users or even your own staff when linking to external sites. My recommendations in short: 1. Use one-time tickets to verify then intent whenever a user performs an action that modifies data. 2. Make sure the application is fully protected from cross-site-scripting (and in this case cross-user-scripting) issues. 3. If your intention is that the users are not allowed to link directly into your application then use Referer checks, but do not rely on this for verifying intent. There are other measurements much more reliable. 4. Do not rely on the client IP in session management. There are plenty of legitimate cases where the client IP is not static and may change in between two requests of the same session. 5. Use SSL to encrypt the traffic. However, compared to the basic risks discussed here encryption is only a minor thing, and won't by itself solve anything. -- Henrik Nordstrom Squid HTTP proxy developer Tim Nowaczyk wrote: > My company implemented this but went one more step. They > created a file that had (IP, ticket) pairs. The ticket was > passed around in URLs, but wasn't valid unless it came from > the specific IP. To pretend to be someone else, one would > have to spoof their IP and guess the value of their (10 hour > life-cycle) ticket. We did this, originally, because we > wanted to support web browsers that didn't use cookies. > The file was, actually, more like (IP, ticket, > cookie-type-options-and-settings). It worked well for us. > > Sincerely, > Tim Nowaczyk > > <>< Truth
This archive was generated by hypermail 2b30 : Mon Jun 18 2001 - 22:32:52 PDT