| Re: Magic quotes? Should I still be cautious? [message #176470 is a reply to message #176469] |
Sun, 08 January 2012 01:33   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 1/7/2012 8:13 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>>> Let's consider an example: A site is available in several languages and
>>> the user can choose a language by clicking on a link (which sends a GET
>>> variable like "lang=de"). The selected language will be stored in a
>>> cookie ("lang=de"), so next time the user visits the site their
>>> preferred language will already be selected. Now on every request the
>>> site checks if there is a "lang" variable (coming from any source) and
>>> sets the proper language accordingly and if the language differs from
>>> the previous one, the lang cookie will be set. A forced distinction
>>> between GET and COOKIE doesn't seem very intelligent to me here. And
>>> even if lang came via POST -- what would it matter?
>>
>> Which would be incorrect. Because if it comes from a cookie, there is
>> no need to display the language selection page or options (unless the
>> user requests a different language). There is also no need to set the
>> cookie.
>
> The language selection/options are always displayed, the current
> language being "highlighted" or otherwise emphasized. And the cookie is
> set only if the choosen new language differs from the current language.
> Yes, that means when a new session is started and the cookie with the
> previous selection is sent, there will be one unnecessary setcookie()
> call, which, however, will do no harm. Alternatively, the user might
> have bookmarked a link containing the lang GET parameter... it's really
> simpler and more convenient to ignore the source of the lang parameter
> here and I definitely do not see any security issue here.
>
That's your first mistake. Cookies are completely unrelated to sessions
- except for the session id in PHP. So there is no need for an extra
setcookie() call - except when you have screwed up logic.
>> There is another problem with your way, also. If the server
>> configuration is set such that cookies take precedence over GET or
>> POST values, then the user would never be able to change the language
>> by using $_REQUEST. And since this is server-configuration sensitive,
>> changes to the server configuration or moving to a different server
>> can break otherwise working code.
>
> This is absolutely true and I had mentioned it some postings ago. And
> actually I would not use $_REQUEST, but rather write a utility input
> function that will look for the desired parameter in GET, POST, COOKIE
> (in precisely that order), but using the filter_input() function instead
> of the superglobals (to avoid the magic quotes issue). This way I'm not
> dependent on the server configuration.
>
Or, rather, look for it where you EXPECT it to occur, and nowhere else.
>>> But lets say we have something more serious, like "delete=all", supposed
>>> to come via POST. Sure, if this came via COOKIE it would certainly be
>>> wrong. If it came via GET, well, there might be a legitimate reason --
>
>> There would not be a legitimate reason if the only way to set the
>> value would be from a page via method=POST.
>
There is no way to ensure the value isn't set via a cookie or GET
request. A hacker can easily send it any way he wants. This is a very
basic security concept.
> I may want or need a link to "delete=all" in addition to the form on
> some other page. My business logic should not be concerned with
> presentation issues (such as on which page the delete command appears).
> After all, whether it's a link (GET) or a form (POST) is just a matter
> of presentation. In both cases I must verify that there is a valid
> session, a valid user etc. I know it is semantically wrong to use GET
> for something like "delete", but then this is just an example.
>
Yes and no. Business logic should not be concerned with presentation
issues - but the interface logic MUST be concerned with it for good
security.
> My point is that the concept of GET, POST and COOKIE is a thing with the
> HTTP protocol. My web application is one level above that and should
> thus not be concerned with the low-level details. And I repeat: an evil
> guy can send an evil command by any of the three ways and thus I
> consider it pointless, if not risky, to put any relevance on this. My
> main focus is not to detect an attack, but to prevent it. Checking
> whence the variable came might help detecting some attacks, but proper
> input validation will prevent it and with the latter in place just let
> the attacker come by GET, POST, COOKIE or whatever, it won't make a
> difference.
>
Your web application may be one level above that. But you obviously
don't understand how to properly interface your business logic to the
display logic.
>> It's much less likely when you validate the values via the appropriate
>> method. And if someone does try to send "delete=all" via $_GET, that
>> ip can quickly be barred from any access to the site, stopping the
>> hacker before they can try other methods.
>
> Hm. You seem to be focussed on detecting an attack, rather than on
> preventing it (I'm not saying you are neglecting the latter). An analogy
> just came to my mind: in JavaScript you could check the user agent to
> find out if a special feature is supported or you could test for that
> feature directly. Of course it is simpler and more effective to do the
> latter than the former. The checking where the variable came from is a
> bit like browser sniffing.
>
> Greetings,
> Thomas
>
That is correct. Detection is always the first step in prevention, as
anyone familiar with security understands. You cannot prevent something
you cannot detect.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]