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 #176462 is a reply to message #176453] Sat, 07 January 2012 20:54 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 1/7/2012 11:59 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> I didn't say you didn't need to validate the parameter. But limiting
>> values to the proper operation makes it harder for hackers to break in.
>
> Harder? Well, by a microscopically tiny amount, yes. The Web Developer's
> Toolbar on Firefox has a menu allowing me to change POSTs to GETs and
> vice versa. And I'm sure with Google you can find in 5 minutes a tool
> that lets you choose between GET, POST and COOKIE and has many other
> "hacking features". So, for all practical purposes, I do not consider
> this to make it any harder for hackers.
>
>> It DOES matter where it came from - and data coming in from the wrong
>> variable can get their IP blocked from the site. There is no use
>> making it easy for them.
>
> Yes, but I still feel that this "where-did-it-come-from" check in
> addition to the proper validation you have to do anyway is like putting
> a banana peel on the floor so in case the enemy manages to force the
> iron gate guarded by a three-headed dragon they will slip on it and
> break their neck.
>
> 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.

However, if there is no language cookie set (or the user says he wants a
different language), then the language selection page must be displayed
and the correct response coming from the $_GET or $_POST variable, as
appropriate.

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.

> 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 --
> or not. But even if it comes via POST, I would not accept it unless I
> have a valid session with a valid user logged in who has the privilege
> to delete "all". A script kiddie might try to send "delete=all" via GET,
> but my three-headed dragon at the iron gate should politely refuse that
> request. And if the script kiddie is smart enough to hijack the session
> of a sufficiently privileged user, they will surely not be stupid enough
> to slip on the GET/POST banana peel.
>

There would not be a legitimate reason if the only way to set the value
would be from a page via method=POST.

>> I have people trying to break into the sites I designed almost daily
>> (multiple times daily if you also include SMTP and SSH attacks). None
>> have succeeded.
>
> Would they have succeeded had you allowed any of the three input
> sources? Yes? Then your site is not safe, but it's certainly not due to
> that. No? Well, see, I was right ;-)
>
> Greetings,
> Thomas
>

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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
[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: Sun Nov 24 22:46:49 GMT 2024

Total time taken to generate the page: 0.05365 seconds