This month Aviv Raff is running a month of (third-party) Twitter bugs. The majority of these bugs are XSS or XSRF and allow attackers to send tweets on behalf of a victim. These third-party web sites are effectively offering open relays that provide spammers and malware authors with new distribution channels and as Aviv notes, these vulnerabilities can be used to create twitter worms too.

Of course, this class of problem isn't limited to Twitter. For example, Facebook also has an open API that allows third-party developers to write their own applications that run on the Facebook platform. When the Facebook API first came out, I took a quick look at it and remember noticing that they did a decent job of preventing HTML and JavaScript injection (at least they were thinking about security). Instead of allowing developers to insert arbitrary HTML, Facebook forces them to use FBML. However, that can lead to FBML Injection. Facebook even has its own query language FQL (similar to SQL), which opens the door to FQL injection.

In the end, even if your favorite social networking websites were secure and never fell prey to another vulnerability (yeah, right), we still need to contend with all of the third-party apps that use their APIs. API providers should include documentation about security in their developer guides. Twitter recently added a Security Best Practices page in their developer section, but I'd like to see security documentation in-line (explicitly included with code examples) rather than a footnote or reference section.

Jeremiah's done an excellent write up on the value of fixing vulnerable code that's even when the vulnerability has been mitigated with a WAF solution. Unfortunately, there's no retweet feature for blog posts, so I'll just add a direct link to Grossman's post.

Technorati Tags: waf vulnerabilities grossman

Several months ago, the Fortify Security Research Group (SRG) published Crypto Manifesto -- a technical note that contains the guidelines for the usage of various cryptographic algorithms in a variety of popular programming languages. The blog entry that accompanied this publication is here. One of the guidelines we gave in the paper (and that we enforce in Fortify Secure Coding Rulepacks) states that keys for symmetric encryption algorithms (such as AES) should be no less than 128 bits in length, naturally implying that keys of 192 and 256 bits are better or at least are as good as those of 128 bits. It turns out, though, that this might not actually be the case.

A recent paper describes new cryptanalytic attacks on AES that are better than brute force. The attacks work only on AES-192 and AES-256, and the idea used for these attacks does not apply to AES-128, making it theoretically stronger than the other two variants of the block cipher, at least against these attacks. Interestingly enough, the attacks are based on the idea of local collisions -- the notion derived from the cryptanalysis of hash algorithms. This means that these attacks will have implications on AES-based hash functions. The publication of the paper raised many interesting questions about security of AES, and a lot of them are addressed by the authors in their FAQ.

How does this affect the guidance we've been giving? We do not think it does. Even though the new attacks are better than brute force, they are still a long way from being practical. As far as we are concerned, symmetric keys of 128, 192, and 256 (no less than 128) bits might not be safe forever, but they're still safe today.

Technorati Tags: crypto encryption keys AES

One of the challenges of an infosec practitioner is remaining knowledgeable about the emerging threats coming down the pipeline. The following are some of the online resources I leverage to seek out emerging threats and as well as manage the information:

• Google Alerts - This tool is a no brainer. As with any other Google alert, simply supply your search terms and sit back as Google does its magic. A few of search terms I have plugged in are "hacked security computer", and "security data breach databreach" "sql injection xss" with a configuration to email me the results once a day. Overall, this simple email alert is a very effective way to be updated on recent breaches.
• XSSed Alerts - XSSed.org is a site were users report cross-site scripting vulnerabilities as they are found. The site also allows one to monitor domains for newly discovered vulnerabilities. The submitted proofs-of-concept are valuable for determining how various XSS attacks are crafted.
• Twitter - As much as I bash Twitter for their lax security, I have gotten a lot of mileage out of the very active info security community that "tweet". Combined with the very liberal usage of hashtagged topics (#security, #vulnerability, #xss being amongst my favorites), Twitter provides a quick means for seeing what security topics, events, and incidents are "hot" at any given moment.
• RSS feeds - Another no brainer for the list. There's no need to elaborate on the benefits of RSS. Instead, I'll list some of my daily security reads. These are in no particular order of importance:
  • CGISecurity - Website and Application Security News
  • GNUCITIZEN
  • The Security Development Lifecycle
  • Wired: Threat Level
  • ha.ckers.org web application security lab
  • Dark Reading: Snake Bytes
  • Jeremiah Grossman

Technorati Tags: emerging threats