NetWorks Group Blog

If you weren't paying attention during the early Summer months this year, you may have missed the overwhelming rate at which web sites were being publicly compromised and mocked. Often, these sites were prone to compromise due to SQL injection and other common web site vulnerability avenues. Even Barracuda Networks was compromised when apparently they took down their own security product for maintenance and were taken advantage of.

Aside from crisis situations involving now-defunct Certificates Authorities, other SSL news has been making waves in the security community the past week. The Browser Exploit Against SSL/TLS (BEAST) demonstrated by Juliano Rizzo and Thai Duong this past Friday was proof that under a complex set of circumstances, 'secure' information can, in fact, be decrypted by an attacker. While the complexities of this attack are likely to be prohibitive for just any attacker to leverage, the reality of its possibility is enough to take a deep breath and question "what's next?" in the litany of failures for our system of [supposedly] secure web browsing.

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.