Jump to content

Recommended Posts

Hi orange08,

 

I did a quick search with Google and found this article which will hopefully be helpful to you.

 

http://rturf.net/documentum/entry/272/

 

thanks for the link, i have checked and read...

now, i'm more clear about how http header looked like...

but, how attacker can attack through this http header? which part can be injected?

Hi orange08,

 

I did a quick search with Google and found this article which will hopefully be helpful to you.

 

http://rturf.net/documentum/entry/272/

 

thanks for the link, i have checked and read...

now, i'm more clear about how http header looked like...

but, how attacker can attack through this http header? which part can be injected?

 

really need help, please! can't find related resource online...  :(

What part don't use understand ?

 

Lets just say you have a Javascript or PHP use grabs the User-Agent and echo's that to the page

Now the problem is, User-Agent comes from the browser BUT it should NOT be trusted, as it can be changed to anything,

 

for example,

echo $_SERVER['HTTP_USER_AGENT'];

may output

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

 

Nothing wrong with that.. BUT if I changed my User-Agent to

<script>alert('PHP Freaks Rule');</script>

I'll get an alert, this is the basis behind injections, its only a problem when coders don't filter the untrusted data, and some coders think that $_SERVER['anything'] is safe! and they find out the hard way.

What part don't use understand ?

 

Lets just say you have a Javascript or PHP use grabs the User-Agent and echo's that to the page

Now the problem is, User-Agent comes from the browser BUT it should NOT be trusted, as it can be changed to anything,

 

for example,

echo $_SERVER['HTTP_USER_AGENT'];

may output

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

 

Nothing wrong with that.. BUT if I changed my User-Agent to

<script>alert('PHP Freaks Rule');</script>

I'll get an alert, this is the basis behind injections, its only a problem when coders don't filter the untrusted data, and some coders think that $_SERVER['anything'] is safe! and they find out the hard way.

 

how to change User-Agent, please? i'm currently use Live HTTP headers to view my http header...then i try to copy your javascript alert script to my User_Agent and replay it...is this the way?

 

with this test to my own site, the alert didn't appear, but my page become weird...some page display only some images, some display error search, depend on what page i perform the test...so, is my site got hole for such attack? how can i deal/prevent it?

 

thanks for reply!

how to change User-Agent, please? i'm currently use Live HTTP headers to view my http header...then i try to copy your javascript alert script to my User_Agent and replay it...is this the way?

 

with this test to my own site, the alert didn't appear,

No that won't work, your need to send the Header data, use cURL's CURLOPT_USERAGENT

curl_setopt($curl, CURLOPT_USERAGENT, '<script>alert(\'PHP Freaks Rule\')</script>');

 

how can i deal/prevent it?

 

If you are using any of the header info then you need to filter it first, if not then don't worry

 

its only a problem when coders don't filter the untrusted data,

 

how to change User-Agent, please? i'm currently use Live HTTP headers to view my http header...then i try to copy your javascript alert script to my User_Agent and replay it...is this the way?

 

with this test to my own site, the alert didn't appear,

No that won't work, your need to send the Header data, use cURL's CURLOPT_USERAGENT

curl_setopt($curl, CURLOPT_USERAGENT, '<script>alert(\'PHP Freaks Rule\')</script>');

 

how can i deal/prevent it?

 

If you are using any of the header info then you need to filter it first, if not then don't worry

 

its only a problem when coders don't filter the untrusted data,

 

seem that filter user inputs is very important...

 

i have a question here concerning filter input.

 

currently, i'm only filter my $_GET input with mysql_real_escape_string()...

then i'll compare the input with my database data...if the $_GET variable is not exist in my database, then i'll try to stop it...

 

so, in this case, if hacker try to inject javascript to my http header, will he success?

are you using the header info ?

from what i have seen your not, so no

 

If you are using any of the header info then you need to filter it first, if not then don't worry

 

its only a problem when coders don't filter the untrusted data,

are you using the header info ?

from what i have seen your not, so no

 

If you are using any of the header info then you need to filter it first, if not then don't worry

 

its only a problem when coders don't filter the untrusted data,

 

sorry, what's header info? can give me example? i'm very confuse now...

I gave an example in my first post,

 

for example,

echo $_SERVER['HTTP_USER_AGENT'];

may output

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

 

Nothing wrong with that.. BUT if I changed my User-Agent to

<script>alert('PHP Freaks Rule');</script>

I'll get an alert, this is the basis behind injections, its only a problem when coders don't filter the untrusted data, and some coders think that $_SERVER['anything'] is safe! and they find out the hard way.

 

just remember if you use $_SERVER['anything'] then filter it before output or inserting it into a database

just remember if you use $_SERVER['anything'] then filter it before output or inserting it into a database

 

so, $_SERVER['anything'] is header info...i see now...

 

but other variables(accepted from user)that can be appended to the query string should be filtered too...not only limited to $_SERVER['anything'], right?

 

in your opinion, for the accepted user input, need to go through what type of filter, only concerning enough?

before querying a database I convert floats to floats, integers to integers, and mysql_real_escape_string() the strings, before outputting to screen I use htmlentities() on variables that are untrusted (any input I didn't control or filter)

before querying a database I convert floats to floats, integers to integers, and mysql_real_escape_string() the strings, before outputting to screen I use htmlentities() on variables that are untrusted (any input I didn't control or filter)

 

i found urlencode(), filter_var() online...so i just think is it enough for me just using mysql_real_escape_string() for the accepted input and htmlentities() for displaying input...?

i found urlencode(), filter_var() online...so i just think is it enough for me just using mysql_real_escape_string() for the accepted input and htmlentities() for displaying input...?

I am not going to commit to saying yes,

mysql_real_escape_string() is for strings,

 

you may want to read PHP Security by Daniel Egeberg

 

i have another confuse...

 

why to use $_SERVER['anything'], i meant in what situation need to use this...

i never use it in my application...is there any problem i didn't need to use it? really must use it...?

 

i found:

$_SERVER['QUERY_STRING']

$_SERVER['PHP_AUTH_USER']

 

in some code...

'QUERY_STRING'

    The query string, if any, via which the page was accessed.

AKA $_GET AKA  Not secure

 

'PHP_AUTH_USER'

    When running under Apache or IIS (ISAPI on PHP 5) as module doing HTTP authentication this variable is set to the username provided by the user.

again provided by the user not secure

 

I'll admit saying anything is over the top, for example

$_SERVER['SERVER_NAME'] is provide by the server, so that should be fine,

 

the rule is simple, if the user can change it you need to filter it.

'QUERY_STRING'

    The query string, if any, via which the page was accessed.

AKA $_GET AKA  Not secure

 

'PHP_AUTH_USER'

    When running under Apache or IIS (ISAPI on PHP 5) as module doing HTTP authentication this variable is set to the username provided by the user.

again provided by the user not secure

 

I'll admit saying anything is over the top, for example

$_SERVER['SERVER_NAME'] is provide by the server, so that should be fine,

 

the rule is simple, if the user can change it you need to filter it.

 

oh, i'm trying to ask about when to use $_SERVER['anything'] not because of the filter case or anything concerning this thread again...

 

just because when i'm search online for the resources, kept seeing the usage of $_SERVER['anything'], but i myself never use it in my application, so i just thought is that in any case that actually need to use them, but i didn't know and didn't use it...

is it OK for me no need to use $_SERVER['anything']?

 

hope you can provide some information here...

 

thanks!

I have no idea what your asking..

if your not using something then you don't need to filter it, if you need to use $_SERVER then filter it, if you don't use it then you don't need to filter it!

 

if you should use it, well that depends if you need to,

I wouldn't recommend using preg_grep if theirs no need to either!

I have no idea what your asking..

if your not using something then you don't need to filter it, if you need to use $_SERVER then filter it, if you don't use it then you don't need to filter it!

 

if you should use it, well that depends if you need to,

I wouldn't recommend using preg_grep if theirs no need to either!

 

oh...you really didn't get what i'm trying to ask...

but, it's ok...

 

thanks anyway!  :)

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.