xss help

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Hi, my first suggestion for that function would be to include some type check, namely, if the given arg is an array or a single value :)

Also, I was under the impression that all $_GET, $_POST and probably $_COOKIE values are natively String until forced otherwise with type casting?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

That's true, checking for (string) is perhaps a bit pointless... But the numeric checks should still work. I did also include "nohtml" and "noscript" in there - not actual types but still checkable.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Aye, I was referring more to the if (is_int($var)) checks etc, as I thought all values would be strings until changed :)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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...
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post by n00b Saibot »

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...
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

n00b Saibot wrote: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...
Try changing the "/" to a "/?" perhaps.... dunno. It does make sense that it can be misused in that sort of fashion though.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

The url I used to taint PHP_SELF was:

Code: Select all

http://localhost/test.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo
This ofcourse was for the file test.php in the doc root of my machine.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

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.
User avatar
Nathaniel
Forum Contributor
Posts: 396
Joined: Wed Aug 31, 2005 5:58 pm
Location: Arkansas, USA

Post by Nathaniel »

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?
yum-jelly
Forum Commoner
Posts: 98
Joined: Sat Oct 29, 2005 9:16 pm

Post by yum-jelly »

$_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
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

$_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.
Where does it come from then? ;) I mean do you actually know with 100% certainty where every $_SERVER variable is sourced? Because surprise surprise - that exploit has been highlighted several times by the Rasmus (God of PHP) and if you look through the source of a certain PHP.net application (http://viewcvs.php.net/viewcvs.cgi/php-bugs-web/) guess what's listed in the updates of 5 months ago?

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

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)
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post by n00b Saibot »

I am a bit shaken now. I tried this extensively and found out that though it does depend on server configurations, such a vulnerability is there and is very dangerous. I have now successfully applied this on some sites. As I noted few times back, Yahoo is particularly lapse in security 8O grrr...
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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):

Code: Select all

header('Location: ' . $_GET['myurl']);
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...
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post by n00b Saibot »

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 :arrow: 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 8)
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

yum-jelly wrote:$_SERVER['PHP_SELF'] is not generated from the URI/URL so it is not tainted.
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.

$_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.
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.
Glad you liked it. :-)

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/
Post Reply