| Re: Data injection problems [message #169607 is a reply to message #169586] |
Sat, 18 September 2010 21:25   |
Michael Fesser
Messages: 215
Registered: September 2010
Karma:
|
Senior Member |
|
|
.oO(Stephan Bird)
> On Sat, 18 Sep 2010 11:32:24 +0200 in
> 1l199652q821h5celav9s6sv2sjbl2v943(at)mfesser(dot)de, Michael Fesser wrote:
>
>> .oO(Michael Fesser)
>>
>>> Same here. I don't have the time right now to investigate a bit further,
>>> but I see at least some problems in the PHP code. At the end there are
>>> includes which include files via HTTP, even if they're on the same
>>> server. While this not only causes a lot of overhead, it could also be
>>> possible that somewhere else in the code there might be a code injection
>>> vulnerability. Or the server was compromised and automatically adds this
>>> code, unless it recognizes some know user agents. As said - in my Opera
>>> the code is clean.
>>
>> Short addition: Opera and Firefox show clean code, Lynx gets the spam.
>>
>> And BTW the page is also vulnerable to cross-site scripting because of
>> things like this:
>>
>> […] value="<?php echo $_REQUEST['backpack'] ?> […]
>>
>
> Thanks for this - any way to harden against this?
Have a look at htmlspecialchars(). Always use it when you have to write
any arbitrary data to an HTML page. This not only includes user input
like above, but also strings from a database for example. Unless you
know exactly and definitely what these strings are and which characters
they contain, pass them through htmlspecialchars().
If used consistently, it not only prevents cross-site scripting, but
also broken markup. If in the code above the posted value would contain
a double quote for example, the resulting markup would be invalid and
probaly result in a broken page. Unlikely in this case, but the typical
example here would be the use of single quotes in the markup and an
attribute value like "O'Neill" for example. Then the result would be
value='O'Neill', leading to invalid markup and a broken form.
And while we're at it, you should also avoid $_REQUEST. This array
contains data from three(!) different sources. It can be useful in some
rare cases, but the recommended way for forms is to use the array which
corresponds to the used form method, i.e. $_GET or $_POST.
> I was aiming to return
> to the form in the case of missing data with previous entries still filled
> out, otherwise to submit.
This is correct and how it should be.
> I have changed the password, re-uploaded as suggested upstream but the
> spurious links come back - does this suggest a problem with my server then?
IMHO yes. You should ask your host.
Micha
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]