{"id":401,"date":"2010-02-23T20:30:16","date_gmt":"2010-02-24T02:30:16","guid":{"rendered":"http:\/\/www.webadminblog.com\/?p=401"},"modified":"2010-02-23T20:32:14","modified_gmt":"2010-02-24T02:32:14","slug":"a-xss-vulnerability-in-almost-every-php-form-ive-ever-written","status":"publish","type":"post","link":"https:\/\/www.webadminblog.com\/index.php\/2010\/02\/23\/a-xss-vulnerability-in-almost-every-php-form-ive-ever-written\/","title":{"rendered":"A XSS Vulnerability in Almost Every PHP Form I&#8217;ve Ever Written"},"content":{"rendered":"<p>I&#8217;ve spent a lot of time over the past few months writing an enterprise application in PHP.\u00a0 Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code.\u00a0 Anyway, I&#8217;m at the point in my development lifecycle where I decided that it was ready to run an application vulnerability scanner against it.\u00a0 What I found was interesting and I think it&#8217;s worth sharing with you all.<\/p>\n<p>Let me preface this by saying that I&#8217;m the guy who gives the training to our developers on the OWASP Top 10, writing secure code, etc.\u00a0 I&#8217;d like to think that I have a pretty good handle on programming best practices, input validation, and HTML encoding.\u00a0 I built all kinds of validation into this application and thought that the vulnerability scan would come up empty.\u00a0 For the most part I was right, but there was one vulnerability, one flaw in particular, that found it&#8217;s way into every form in my application.\u00a0 In fact, I realized that I&#8217;ve made this exact same mistake in almost every PHP form that I&#8217;ve ever written.\u00a0 Talk about a humbling experience.<\/p>\n<p>So here&#8217;s what happened.\u00a0 I created a simple page with a form where the results of that form are submitted back to the page itself for processing.\u00a0 Let&#8217;s assume it looks something like this:<\/p>\n<pre>&lt;<a href=\"http:\/\/december.com\/html\/4\/element\/html.html\">html<\/a>&gt;\r\n &lt;<a href=\"http:\/\/december.com\/html\/4\/element\/body.html\">body<\/a>&gt;\r\n  &lt;?php\r\n  if (isset($_REQUEST['submitted']) &amp;&amp; $_REQUEST['submitted'] == '1') {\r\n    echo \"Form submitted!\";\r\n  }\r\n  ?&gt;\r\n  &lt;<a href=\"http:\/\/december.com\/html\/4\/element\/form.html\">form<\/a> action=\"&lt;?php echo $_SERVER['PHP_SELF']; ?&gt;\"&gt;\r\n   &lt;<a href=\"http:\/\/december.com\/html\/4\/element\/input.html\">input<\/a> type=\"hidden\" name=\"submitted\" value=\"1\" \/&gt;\r\n   &lt;<a href=\"http:\/\/december.com\/html\/4\/element\/input.html\">input<\/a> type=\"submit\" value=\"Submit!\" \/&gt;\r\n  &lt;\/<a href=\"http:\/\/december.com\/html\/4\/element\/form.html\">form<\/a>&gt;\r\n &lt;\/<a href=\"http:\/\/december.com\/html\/4\/element\/body.html\">body<\/a>&gt;\r\n&lt;\/<a href=\"http:\/\/december.com\/html\/4\/element\/html.html\">html<\/a>&gt;\r\n<\/pre>\n<p>It looks fairly straightforward, right?  The problem has to do with that $_SERVER[&#8216;PHP_SELF&#8217;] variable.  The intent here is that PHP will display the path and name of the current page so that the form knows to submit back to the same page.\u00a0 The problem is that $_SERVER[&#8216;PHP_SELF&#8217;] can actually be manipulated by the user.\u00a0 Let&#8217;s say as the user I change the URL from https:\/\/www.webadminblog.com\/example.php to https:\/\/www.webadminblog.com\/example.php&#8221;&gt;&lt;script&gt;alert(&#8216;xss&#8217;);&lt;\/script&gt;.\u00a0 This will end the form action part of the code and inject a javascript alert into the page.\u00a0 This is the very definition of cross site scripting.\u00a0 I can&#8217;t believe that with as long as I&#8217;ve been writing in PHP and as  long as I&#8217;ve been studying application security, I&#8217;ve never realized this.\u00a0 Fortunately, there are a couple of different ways to fix this.\u00a0 First, you could use the HTML entities or HTML special character functions to sanitize the user input like this:<\/p>\n<p>htmlentities($_SERVER[&#8216;PHP_SELF]);<\/p>\n<p>htmlspecialchars($_SERVER[&#8216;PHP_SELF]);<\/p>\n<p>This fix would still allow the user to manipulate the URL, and thus, what is displayed on the page, but it would render the javascript invalid.\u00a0 The second way to fix this is to use the script name variable instead like this:<\/p>\n<p>$_SERVER[&#8216;SCRIPT_NAME&#8217;];<\/p>\n<p>This fix would just echo the full path and filename of the current file.\u00a0\u00a0\u00a0 Yes, there are other ways to fix this.\u00a0 Yes, my code example above for the XSS exploit doesn&#8217;t do anything other than display a javascript alert.\u00a0 I just wanted to draw attention to this issue because if it&#8217;s found it&#8217;s way into my code, then perhaps it&#8217;s found it&#8217;s way into yours as well.\u00a0 Happy coding!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I&#8217;ve spent a lot of time over the past few months writing an enterprise application in PHP.\u00a0 Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code.\u00a0 Anyway, I&#8217;m at the point in my development lifecycle where I decided that it was [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[4],"tags":[175,396,395,161,393,394,177,176,10,174],"class_list":["post-401","post","type-post","status-publish","format-standard","hentry","category-web-app-sec","tag-cross","tag-cross-site","tag-form","tag-php","tag-php_self","tag-post","tag-scripting","tag-site","tag-vulnerability","tag-xss"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pfI0c-6t","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/posts\/401","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/comments?post=401"}],"version-history":[{"count":7,"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/posts\/401\/revisions"}],"predecessor-version":[{"id":481,"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/posts\/401\/revisions\/481"}],"wp:attachment":[{"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/media?parent=401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/categories?post=401"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webadminblog.com\/index.php\/wp-json\/wp\/v2\/tags?post=401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}