American Express Leaves a Door Wide-Open

Not to be left in the dust for instances of confusingly-bad security practices by industry friends such as Citibank and Bank of America, American Express served up their own face-palm of security today. In this case, it appears that a breakdown between application developer ease-of-debugging didn't quite mesh-up with operations security and access restrictions. To summarize the link, American Express failed to effectively restrict a developer interface which provides debugging functionality for developers working on their web site.

These sorts of administrative interfaces are certainly not uncommon, but they should be by design restricted to people with proper credentials or at least blocked from the public Internet for accessibility.Interestingly enough, the American Express 'robots.txt' file, often used to tell search engine indexers not to bother certain portions of a web site, list these unrestricted URLs plain-as-day. Again, using robots.txt is not a bad thing alone, but if that points to otherwise 'hidden' directories which provide functionality not intended for the general public, you've got a new problem to fix.Technology is often discussed as a trade-off between convenience and security. I don't think this concept could be anymore obvious in this situation of a security blunder. American Express provided developer access to easily debug the web site and test functionality. In doing so, they removed a large amount of security into private processes that should not otherwise be exposed. Beyond just being 'bad practice' and exposing information not suitable for public access, they actually introduced a cross-site scripting (XSS) vulnerability into americanexpress.com due to this situation. That then opens the door for an attack to potentially phish accounts of unassuming users.

In this case, the above link's poster went the 'full disclosure' route and made a scene on Twitter and elsewhere to talk about what he found. While this certainly left American Express exposed for the half-a-day that they were publicly vulnerable, who knows if other attackers had found this and were actively utilizing it for their own ends prior.To that end, it's up to a company like American Express to do simple vulnerability assurance testing on not just public pages, but also on (assumed) private pages. Having a XSS vulnerability should not be acceptable even if the page is never intended to be public. Defense in depth could have prevented this XSS situation at various levels: access controls for the developer panel; network restrictions to the developer panel; not placing administrative pages in robots.txt; vulnerability testing internal application. If one of these had been true, the entire situation would have never arisen. Luckily in this situation, no direct customer data was at risk (as reported thus far). Still, financial institutions should never be prime examples of failing information security practices in so many drastic ways.