Re: The Dangers of Allowing Users to Post Images

[Henrik Nordstrom <hno () hem passagen se>]

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