Here's a fun story about XSS and why we should take it seriously.

Due to the location of my residence and the ineptness of my HOA, the buildings around me get fiber optic, but I can't. So I use Qwest DSL for my home internet access. While I'm not a huge fan of the company, they generally tend to get things done and not cause me too much grief. There's a lot I don't like, but not enough to quit using their service.

About a year ago, I was paying my bills and visited the "My Profile" page. Out of curiosity, I stuck a few quotes and HTML tags into a few fields and much to my surprise (not really), found some permanent XSS holes. While I don't like seeing it, this alone isn't really news (as evidenced by the recent string of holes we've been finding on bank and credit company websites). I left one field set to pop up an alert box every time I log in and mostly forgot about it.



A few months later there was an internet outage. The Tech Support call was a whole 'nother adventure (what "scheduled router maintenance" results in a 30+ hour outage? There's something they weren't telling me), but the interesting part was when the rep brought up my account information. She sounded confused on the phone, said something like "what's this? This is weird..." and after a few loud clicks, seemed to get back on track and finish the call. It wasn't until after I hung up that I realized what had happened- my XSS has executed in the context of a Tech Support rep, who presumably has access to other accounts, network information, and other goodies...

I never did anything with it, but did mention it to a few of Qwest's IT people I met a few months later. They didn't seem too concerned. I then looked through the Qwest website a bit more and found a few more XSS holes- these ones in the public side. I reported them, posted them on XSSed, and forgot about them. They never did get fixed.

While finding security holes in the financial sector seems to be all the rage these days, I'm going to focus for the next while on some public utilities. Frankly, they scare me more- they're often government owned and operated, so have less market-driven controls in place. Most of them know your Social Security number, your credit card number, your checking account information, and they directly affect your everyday life.

Wouldn't it be scary if your power company used outdated perl scripts to handle billing and account management? Mine does.

With Russ's latest blog post came links to a few articles dealing with the recently exposed American Express XSS holes. In short, AmEx dealt with it badly- ignoring Russ's three attempts to contact them and only fixing the issue when it got posted publicly (after their PR watchdogs brought the post to their attention).

One of the more interesting articles was at BetaNews. Please read it.

I don't think that AmEx's web developers read my blog (at least I haven't seen many related IPs pop up in my logs), but maybe they should. Their primary excuse for not fixing the flaw is that it didn't get to the right people.

Now, exactly whose fault is that?

I wrote a few months ago, in my "Open Letter to The Internet" that website owners need to make it painless to report security issues. If they don't provide a simple process for doing so, I have a hard time feeling sorry for them. Russ's goal was to get the bug fixed, and contacting the company didn't do it. Once he posted it publicly, people actually started caring. (Unfortunately, the fix only lasted a day before getting broken by two more researchers, which makes me think that AmEx's programmers are inept to begin with).

Russ made a good-faith attempt to contact the company not one, but three times. He sent messages to two different entities and gave them two weeks to respond. If it had been me reporting the bugs, I certainly wouldn't have given them that much effort unless I was on their payroll.

As I wrote back in August, "We are here to help, but we aren't necessarily here to help you."

I just upgraded a few servers to the latest version of cPanel, which is supposedly fully PCI compliant.

You may be wondering why, with its massively widespread use, cPanel wasn't already PCI compliant. Basically it dealt with a variety of SSL issues- the administration interface supported weak SSL ciphers and there was no way to change that through cPanel. You had to hack it together, disabling cPanel's internal SSL libraries and using other tools to implement it properly.

While I'm happy that they got around to fixing that issue (after only about 4 months), they still haven't fixed the XSS or CSRF issues that I sent to them in June and posted here back in August.

...But I'm getting awfully jaded, and I'm not expecting them to ever fix it.

I don't think this is news to the other security people, but as a developer, I had never heard of this issue. As far as I know, none of the developers I regularly work with had heard of it either (though using the code as recommended by the php.net manual will prevent it).

In many PHP applications, there is an admin side and a public side. It is common for developers to have an "admin check" in the code header of the admin side, which essentially evaluates whether a user is authorised to view a resource and either redirects them to the login page, the public page, or lets them through to the resource.

What many developers don't realize is that a browser doesn't have to terminate a connection as soon as it receives a 302 redirect. If you are relying on the following call to keep the riffraff out of your admin pages, you may be vulnerable:

header('Location: login.php');

I can't tell you how many times I've been able to access reports full of user logins, order information, or even account modification functionality, simply by asking my browser to continue loading a page after receiving a redirect. If you need a testing tool to see if you are vulnerable, I whipped up this perl script one day to allow me to simply snag admin pages or post content to them during a penetration test.

In case it isn't obvious, you can prevent this hole simply by halting the flow of the application. If you aren't using more advanced templating and flow control (which I'd recommend anyways), this will work:

header('Location: login.php');
die('Kindly piss off.');

While obvious, this issue is incredibly widespread, and I have to wonder how many developers are unaware of it.

I found this a few months ago and have been racking my brain for a way to use it in a pentest. Maybe somebody else can find a practical exploit for this; so far, I have nothing. I do think it's kind of funny though.

With display_errors on, PHP will send errors to the browser, along with the location of the buggy code. This is often useful for debugging, and helpful to malicious users. Interestingly, it doesn't filter the filename for HTML characters.

If you were able to, say, create a folder named "<script>alert(1337)<", and within it, place a file called "script>.php", which in turn threw an error, you'd get something like this.