Re: Redirect
From: John Bokma (postmaster_at_castleamber.com)
Date: 03/09/05
- Next message: John Bokma: "Re: Passing data from PHP to Perl?"
- Previous message: Tony Marston: "Re: Questions on size of session"
- In reply to: Michael Fesser: "Re: Redirect"
- Next in thread: J.A.: "Re: Redirect"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 9 Mar 2005 06:47:17 GMT
Michael Fesser wrote:
> .oO(John Bokma)
>
>>Michael Fesser wrote:
>>
>>> You wrote "reject it, don't fix it", I simply asked why not.
>>
>>My question was important. (How did it get broke)
>
> Users can submit whatever they like, there's no way to prevent that.
You can prevent a lot of things by setting limits on form elements.
Note: I don't say that you rely on it, but if an input field has a
maxlength of 100 chars, and you get 101, the user is most likely not
using the form.
>>> No. But I try to fix/interpret the submitted data if necessary.
>>
>>How? Imagine a link id is a number between 1 and 5000. You want to
>>silently fix it if you get aaax or 999999? It's called defensive
>>programming, and it's wrong. Why? Because if the ID happens due to a
>>programming error in your code, the rest keeps running like nothing
>>happens, and you might waste hours, or more on debugging.
>
> The program knows the valid range, the user is still able to send
> garbage.
Yes, and if it's garbage on purpose, don't fix it.
> I validate the submitted data and fix it if possible, any
> following functions work with the corrected value.
Which can be wrong. Mind, with fixing I mean you expect a link_id which
should be an integer and you get link_id=foo (and not via a form).
>>How did it get longer? You can use HTML to limit the size.
>
> Not really. It's a suggestion, nothing more.
How can you type beyond the suggestion?
> Even "disabled" or
> "readonly" in form fields are just suggestions, they prevent nothing.
Ah, but I didn't say you should *rely* on them.
>>Note that I
>>don't write that you have to rely on this!
>
> Simply because you can't rely on that. Users can manipulate
> everything.
Yup, and then they are doing nasty things which you *shouldn't* fix for
them.
>>So if in my FORM I have set a
>>max limit on password, say 20 characters, and I get 21? How did this
>>happen?
>>
>>1) the user was able to send me 21 characters
>>2) I forgot the limit
>>3) I made somewhere a mistake
>
> 4) The user considers himself a hacker and sends malicious data to see
> what happens. Manipulating GET parameters is trivial, with POST it's a
> bit more complicated, but still possible.
And do you now understand that fixing 4 is just plain stupid? It's not a
normal user, so why should you fix his or her requests? You have not
even a clue what he / she wants.
>>Trimming it to 20 and accepting it, is wrong.
>
> Why?
See above.
>>> if a numeric
>>> value is out of the expected range I correct it, ...
>>
>>How? By setting it to max or min?
>
> Yep.
Bzzzt, wrong.
>>Is that what the visitor expects to
>>get?
>
> Does the visitor expect an error message?
Suppose I enter as my age 1380. Your program is going to fix this (what
will it be), my program will give an error.
Suppose I want a password to be max 20 characters. The user somehow
managed to enter 21 characters. Your program is going to fix this (which
can cause a problem). My program is going to reject it.
>>And how did it get out of this range?
>
> It's possible, that's reason enough for me.
Yes, but fixing it is wrong.
>>Again, it's wrong. You make mistakes in your program (or HTML)
>>extremely hard to find.
>
> I don't think so.
Yeah, that's clear. Think a bit harder.
>>Imagine: you have a link in your page, and you want to pass on id 399:
>>
>>Foo bar recipe
>>
>>When are you discovering this mistake? If the max ID is 2000, you
>>"fix" 3999 as 2000, and hence your visitors see a page with ID 2000...
>
> Yep, something like that.
Which is wrong.
> Another example: A field for entering a date. The processing script
> simply has to be able to interpret different date formats. You can't
> force the user to exactly follow your preferences and use yyyy-mm-dd
> or something like that.
>
> Fairly recently I came across a site that asked for my birthday in a
> registration form. I entered it in the form yyyy-m-d without leading
> zeros. The stupid script complained ... fixing that silently would
> have been trivial.
Ah, but that is *not* what I mean. Read better: If you specify that both
yyyy-mm-dd and yyyy-m-d are accepted input, you are *not* fixing it, but
accepting it (and reformatting it to an internal presentation, but
that's not fixing either).
>>> Showing an error message is always my last option, if everything
>>> else failed.
>>
>>If the input is unexpected it should be the first option.
>
> Actually I don't see a problem with trying to interpret/fix the
> submitted data first.
I hope you do now, since most security related problems, and many bugs
are caused by programmers who go at great length to think for their
users.
-- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html
- Next message: John Bokma: "Re: Passing data from PHP to Perl?"
- Previous message: Tony Marston: "Re: Questions on size of session"
- In reply to: Michael Fesser: "Re: Redirect"
- Next in thread: J.A.: "Re: Redirect"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
