FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Magic quotes? Should I still be cautious?
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Magic quotes? Should I still be cautious? [message #176469 is a reply to message #176462] Sun, 08 January 2012 01:13 Go to previous messageGo to previous message
Thomas Mlynarczyk is currently offline  Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma:
Senior Member
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.

> 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.

>> 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.

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.

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.

> 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

--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Lilupophilupop
Next Topic: [WSP] CALL FOR PAPERS [FREE]
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Mon Nov 25 01:25:09 GMT 2024

Total time taken to generate the page: 0.04439 seconds