Also, I was under the impression that all $_GET, $_POST and probably $_COOKIE values are natively String until forced otherwise with type casting?
xss help
Moderator: General Moderators
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
is_numeric() would work, or maybe ctype_digit()? Some of the ctype functions would be useful for strict cases, otherwise we're all off to regex land...
About nohtml - what if the HTML was encoded? (i.e. an encoding of an encoded string - one possible attack on textareas in IE6 - i think.) Maybe html_decode_entities(), then check, then maybe a htmlentities($data, ENT_QUOTES, 'utf-8') after?
String can be broken down even further depending on expected characters - could be anything in there at all... usernames, passwords, alphabetic, alphanumeric, other specific string formats (email, spaced, implodes). Anything outside the covered types would probably be nohtml (since it wouldn't be specifically whitelisted). Even some specific string types might still need nohtml-like filtering if they're allowed to contain html like special chars.
On expectations - two other checks: Keys and Maxlengths. Forms can be forged to bypass maxlength, and we all know about the deadly keys and register_globals on cocktail...
About nohtml - what if the HTML was encoded? (i.e. an encoding of an encoded string - one possible attack on textareas in IE6 - i think.) Maybe html_decode_entities(), then check, then maybe a htmlentities($data, ENT_QUOTES, 'utf-8') after?
String can be broken down even further depending on expected characters - could be anything in there at all... usernames, passwords, alphabetic, alphanumeric, other specific string formats (email, spaced, implodes). Anything outside the covered types would probably be nohtml (since it wouldn't be specifically whitelisted). Even some specific string types might still need nohtml-like filtering if they're allowed to contain html like special chars.
On expectations - two other checks: Keys and Maxlengths. Forms can be forged to bypass maxlength, and we all know about the deadly keys and register_globals on cocktail...
- n00b Saibot
- DevNet Resident
- Posts: 1452
- Joined: Fri Dec 24, 2004 2:59 am
- Location: Lucknow, UP, India
- Contact:
Hey Maugrim! I couldn't successfully execute the url that you posted for tainting PHP_SELF
Are you sure it works in every case
'cause I tried it in atleast dozen places and nowhere it retuned successfull. In every case the server responded with HTTP Not Found error... why 
I tried to execute it since I have used PHP_SELF extensively and I was 100% positive of the notion that it couldn't be changed... now can you prove that thing out?
Thanks...
I tried to execute it since I have used PHP_SELF extensively and I was 100% positive of the notion that it couldn't be changed... now can you prove that thing out?
Thanks...
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Try changing the "/" to a "/?" perhaps.... dunno. It does make sense that it can be misused in that sort of fashion though.n00b Saibot wrote:Hey Maugrim! I couldn't successfully execute the url that you posted for tainting PHP_SELFAre you sure it works in every case
'cause I tried it in atleast dozen places and nowhere it retuned successfull. In every case the server responded with HTTP Not Found error... why
I tried to execute it since I have used PHP_SELF extensively and I was 100% positive of the notion that it couldn't be changed... now can you prove that thing out?
Thanks...
The url I used to taint PHP_SELF was:
This ofcourse was for the file test.php in the doc root of my machine.
Code: Select all
http://localhost/test.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Fudge... I see it now. Loads and loads of errors if you add that extra slash.
Is this like a feature of Apache's or something? I should turn it off: there is _no_ reason for http://www.example.com/index.php/ to work without explicitly saying so.
Is this like a feature of Apache's or something? I should turn it off: there is _no_ reason for http://www.example.com/index.php/ to work without explicitly saying so.
$_SERVER['PHP_SELF'] is not generated from the URI/URL so it is not tainted. All the examples I have seen here don't show any XSS problem. If you were using mod_rewrite than you would be sent to a 400.? because the rewrite rule regex would never match the example. Now rewrite rules can get you into trouble but they have nothing to do with all $_SERVER scoped variables being tainted, especial $_SERVER['PHP_SELF']!
yj
yj
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Where does it come from then?$_SERVER['PHP_SELF'] is not generated from the URI/URL so it is not tainted. All the examples I have seen here don't show any XSS problem.
What about other SERVER variables, let's not forget a similar request could also lead to:
$_SERVER["PATH_INFO"] = /<xss>
$_SERVER["PATH_TRANSLATED"] = /var/www/dom/<xss>
$_SERVER["PHP_SELF"] = /index.php/<xss>
If you want a more obscure XSS exploits take a tour across Google looking for "php://" and streams (PHP5).
These aren't concocted stories, they are real XSS exploits. Unfortunately ignorance makes these very dangerous. At the end of the day the best defense against any security exploit is knowledge. You can't prevent exploits that you are not even aware of...
mod_rewrite. This allows the "nice" url effects you see on some applications to make urls more search engine friendly (bots often ignore the query string in urls), among other things. It's one source (probably a few others) of PHP_SELF tainting.I get 403 forbidden errors on my server when trying your PHP_SELF exploits. Is there a configuration option which allows it to work on some servers and not others?
It depends on having Apache/PHP accept "nice" urls - probably using mod_rewrite. I'm definite it works under the right environment. This was reported as a vulnerability in several applications using PHP_SELF. There are likely more that simply aren't aware of it, unfortunately. On a default environment it will of course fail completely. I haven't looked at it in depth for a few months - the fact it exists was enough for me.Hey Maugrim! I couldn't successfully execute the url that you posted for tainting PHP_SELF. Are you sure it works in every case Question 'cause I tried it in atleast dozen places and nowhere it retuned successfull. In every case the server responded with HTTP Not Found error... why Confused
I tried to execute it since I have used PHP_SELF extensively and I was 100% positive of the notion that it couldn't be changed... now can you prove that thing out?
More recent reference I found:
http://www.phpguru.org/article.php?ne_id=72
Others:
http://lists.nyphp.org/pipermail/talk/2 ... 15537.html
http://php.mirrors.esat.net/manual/en/r ... .php#55068 (PHP Notes)
- n00b Saibot
- DevNet Resident
- Posts: 1452
- Joined: Fri Dec 24, 2004 2:59 am
- Location: Lucknow, UP, India
- Contact:
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
If anyone subscribes - php|architect (online magazine) mentions PHP_SELF as an issue. Just noticed this today after getting around to reading the current edition. Chris runs the "Security Corner" articles for this. Chris also has an interesting article on header injections - what he calls HTTP Response Splitting.
Header injections (for the uninitiated) is what you get when reponse headers are contaminated. Think of the horror of mixing something like PATH_INFO with something like or similar (this is all arbitrary - its down to how you compose that variable used within the header - any header call in fact):
Now consider a user who passes (in $_GET['url']) a url encoded string which adds additional headers, maybe a content type, and some forged html as content.
Horrible thought...
Header injections (for the uninitiated) is what you get when reponse headers are contaminated. Think of the horror of mixing something like PATH_INFO with something like or similar (this is all arbitrary - its down to how you compose that variable used within the header - any header call in fact):
Code: Select all
header('Location: ' . $_GET['myurl']);Horrible thought...
- n00b Saibot
- DevNet Resident
- Posts: 1452
- Joined: Fri Dec 24, 2004 2:59 am
- Location: Lucknow, UP, India
- Contact:
yeah! i have read about this before. and also there is one article over HTTP Request Smuggling in which multiple request headers would be sent in a single specially crafted request which would result in either of these things
1. Web Cache Poisoning
2. Request Credential Hijacking
3. Request Hijacking
4. Firewall Evasion
Article can be found here
http://www.whitedust.net/speaks/825/Apa ... erability/
because of this reason, Apache lauched their newer version which addresses this issue.
I have used it successfully to fetch some content outside Proxy Administrator's knowledge
1. Web Cache Poisoning
2. Request Credential Hijacking
3. Request Hijacking
4. Firewall Evasion
Article can be found here
because of this reason, Apache lauched their newer version which addresses this issue.
I have used it successfully to fetch some content outside Proxy Administrator's knowledge
Please try to be more careful. Spreading misinformation can be damaging. I understand that this is probably accidental, but at least acknowledge any uncertainty that you might have when making a statement. Being certain and being wrong should be mutually exclusive states.yum-jelly wrote:$_SERVER['PHP_SELF'] is not generated from the URI/URL so it is not tainted.
$_SERVER['PHP_SELF'] is a tainted variable.
Apache allows a slash as an IFS (input field separator). Of course, failing to filter any data that originates from a remote source is a mistake, regardless of any other details.
Glad you liked it. :-)Maugrim_The_Reaper wrote:If anyone subscribes - php|architect (online magazine) mentions PHP_SELF as an issue. Just noticed this today after getting around to reading the current edition. Chris runs the "Security Corner" articles for this. Chris also has an interesting article on header injections - what he calls HTTP Response Splitting.
The attack really is called HTTP Response Splitting, although some other names floating around are HTTP Header Injection, HTTP Request Smuggling, and CRLF Injection (ordered from most to least popular alternatives). Sometimes, renames happen when a company wants to be credited with the discovery (e.g., hoping the new name catches on more than the original). Sometimes, it's because the original name is somewhat misleading. Regardless, these efforts really just confuse the whole discipline of web application security. I try to use the original names whenever possible.
There is an effort to try to provide an official classification for threats:
http://webappsec.org/projects/threat/