Re: [BUGTRAQ] Re: never-ending Referer arguments (The Dangers of Allowing Users to Post Images)

From: CDI (cdiat_private)
Date: Tue Jun 19 2001 - 15:07:39 PDT

  • Next message: Mark Tinberg: "Re: [Fwd: Re: Cross-Site Request Forgeries (Re: The Dangers ofAllowing Users to Post Images)]"

    On Tue, 19 Jun 2001, Peter W wrote:
    
    > On Tue, Jun 19, 2001 at 03:44:10PM +0200, Henrik Nordstrom wrote:
    > > peterwat_private wrote:
    > > 
    > > > Folks are missing the point on the Referer check that I suggested.
    > > 
    > > I intentionally selected to not go down that path in my message as there
    > > are quite a bit of pitfalls with Referer, and it can easily be
    > > misunderstood allowing the application designer falsely think they have
    > > done a secure design using Referer.
    > 
    > Henrik,
    > 
    > You also revealed your lack of understanding the Referer check logic when
    
    Snide commentary aside, there seems to be a misunderstanding about
    Referers and their use in any type of validation or check.
    
    Let me see if I can make this as clear as possible:
    
    Using the referer for anything other than statistics gathering to show the
    marketing wonks who is linking to your site would be, and is, a mistake.
    
    Whether the referer exists or not, is correct or not, or is even the
    correct format for a URI should be completely irrelevant. If the referer
    is relevant in -any- way to the integrity of the data you are attempting
    to validate then your security model is broken.
    
    > All this chatter about Referer checks amounts to two things:
    >  - some folks not understanding the model
    
    I understand your model perfectly well and I see it for the fallacy that it
    is. That you apparently cannot see this for yourself is distressing.
    
    I do not see the logic in validating user submitted (form) data with yet
    more user submitted data. Perhaps I'm misunderstanding why you (or anyone
    for that matter) would blindly put any credibility what-so-ever in any user
    input, which includes the Referer.
    
    Your "three-stage security model" has but 1 stage that I can see.  The
    other two steps are sugar coating that add no further benefit to your
    security "model". From one of your previous emails...
    
    > An attacker can trick the victim's browser into sending 1 + 2. Or the
    > attacker himself can send 2 + 3. But the attacker cannot get the victim to
    > send 1 + 2 + 3, unless the application is poorly designed.
    
    By definition an exploitable web application is poorly designed. I can and I
    have written exploits to re-produce not only valid input, but valid cookies
    and referer data all in the same instant. The victim didn't even need to
    click a link - they just opened their webmail and the application was
    instantly compromised - I had their cookies, the URL data and the referer
    all rolled into one. The webmail was compromised because my exploit
    successfully reproduced all three of your security stages.
    
    Every single "crack" out there - from brute forcing passwords to overruning
    buffers is dependant upon one thing: Improper validation of user supplied or
    manipulated data. If you decide to treat the Referer as anything other than
    what it is, untrustworthy user data, you do so at your peril.
    
    >  - folks legitiately disagreeing on the number of user who might be
    >    locked out by a Referer check.
    
    Those that check the referer for purposes beyond statistical or marketing
    needs are just wasting time. It can not and will not make the data any safer
    or more trustworthy.
    
    CDI
    ____________________________________
    The Web Master's Net
    http://www.thewebmasters.net/
     "I would imagine even a trained MSCE-monkey can run a virus scan...
      OW! What the hell? Ack! Help! Idealism is biting me on the ass!   
      Get it off! Get it off!"  -- Andrew Boring in the Monastery
    



    This archive was generated by hypermail 2b30 : Fri Jun 22 2001 - 13:44:34 PDT