Today is the first day of the infamous Black Hat Briefings taking place at the Black Hat Conference in Las Vegas and most of what the attendees will hear today is being presented publicly for the first time by the various researchers in the building. Today, for example, is the day that many researchers reveal their discoveries and exploits but in some cases, they hold back on the tools or details needed to replicate their research until the impacted vendors and organizations have an opportunity to address the vulnerabilities. Case in point: a team of researchers used NewsWeek.com as an example of a site that's vulnerable to dynamic cross site request forgeries.

Cross site request forgeries are not a new phenomenon on the Web. Abbreviated as "CSRF" and pronounced "sea-serf" and a kissing cousin to Cross-Site Scripting (XSS), it's a type of phishing attack where a user visits one site (eg: a social networking site) while they're still authenticated as user on another site (eg: their bank's web site). This could be in another tab on the browser or it could be through an unexpired session (even though no browser tab or window is open to that site). With a CSRF, in the course of accessing the social networking site, the user encounters something in the HTML that refers to a script on the banking site. For example, a script to change the password. The pointer to the script could appear in something as simple as an HTML image tag and given the massive proliferation of images across social networking and user generated content (UGC) sites and the blind trust that millions of users place in the content they're viewing on those sites, user generated content in aggregate represents a massive CSRF attack vector.

That is one key message of two researchers who gave their briefing this morning here at Black Hat: Shawn Moyer, a hacker on the Security Assessments Team at Fishnet Security and Nathan Hamiel, a senior security consultant with Idea Information Security. Today at Black Hat, Moyer and Hamiel used a CSRF attack to issue a global password reset command to Newsweek.com.

If you weren't here at Black Hat to see the briefing or are unable to gather enough from the other reports coming out of Black Hat today, then have no fear (no pun intended). I was able to record (for podcast) a personal briefing with Moyer and Hamiel. To listen to it, you can press the tiny in-line play button in the previous sentence, you can pop out the audio player from the tab hanging off the left side of your display, or you can right-click on the link in the previous sentence and download the MP3.

According to Moyer and Hamiel, the viral nature of user-generated content presents another opportunity to those with malicious intent (thus, the social networking angle of the headline). Let's say for example that I post a blog to the Web with a great image that's clean (in other words, nothing malicious about it). But now let's also say it starts to get a lot of traction on a site like Digg.com or Reddit.com. The users on those sites start to vote the content up and eventually, the piece goes completely viral. Once I've got a lot of traffic flowing to my content, I swap out a the great picture that everyone is coming to see for a bad image tag that launches a CSRF attack. According to Hamiel, Digg has precautions that look out for such attacks. But as you'll hear in the podcast, Reddit doesn't employ the same checks and balances and thus, represents part of the social networking surface area for CSRFs.

In the podcast, Hamiel and Moyer also discuss how CSRF attacks aren't just limited to public Web sites. Hamiel has also successfully launched a CSRF attack on a Motorola Netopia DSL modem where he was able to set the remote admin password and permanently set the modem's remote admin mode to the "ON" position. In this case, Hamiel knew which script on the modem to call and how to call it. Figuring out such scripts for devices or Web sites is relatively easy with commonly available tools such as HttpFox -- a plug-in for Firefox that can easily reveal the details behind any HTTP Post. Once a hacker has those details, an attack is just a matter of replaying the post with data (eg: password) furnished by the hacker. In this respect, a CSRF is also known as a "replay attack."

Where the danger arises (not discussed in the podcast) is, let's say you come to my site and on that site, I have an image tag that calls the remote admin script on a Motorola Netopia DSL modem and let's say you happen to have a Netopia DSL modem (now you see why CSRF attacks are a type of phishing attack --- I as the attacker am hoping that someone who visits my site will actually have a Netopia DSL modem). I can call this script because (a) I know that most people are running the modem at its default IP address (eg: 192.168.1.1) with its default password, and (b) I know how to call the remote admin script on that modem, and (c) my traffic logs will show what IP address you visited from (the IP address of that modem). At that point, I have all the information I need to remotely login to your cable modem at which point I basically own your network.

According to the two researchers, there's no single silver bullet to defend against CSRF attacks. With randomly generated tokens per request submitted through a POST function versus a GET, you're much better off than using a static token and sending it with GETs, according to Hamiel. Moyer also pointed out how long-life sessions (one where the authentication to some site lasts days, weeks, or even longer) is another culprit. In this case both the end-user and the Web site operators can take measures. End-users should logout of any site as soon as they're done (instead of just closing the browser). Web site operators shouldn't let sessions endure for any unreasonable amount of time of inactivity.

Such advice however is hard to push on the operators of Web sites looking to make their user experiences as frictionless as possible. Users have an expectation that the sites they visit won't be overly verbose when it comes to requesting login credentials. Such is the conundrum where convenience is often pitted against security.

David Berlind is the chief content officer of TechWeb and editor-in-chief of TechWeb.com. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong and welcomes comments, both for and against anything he writes. He can be reached at [email protected] and you also can find him on Twitter and other social networks (see the list below). David doesn't own any tech stocks. But, if he did, he'd probably buy some Salesforce.com and Amazon, given his belief in the principles of cloud computing and his hope that the stock market can't get much worse. Also, if you're an out-of-work IT professional or someone involved in the business of compliance, he wants to hear from you.

Twitter: (@dberlind) My Facebook Page Flickr (davidberlind) YouTube (TechWebTV) FriendFeed (davidberlind) Del.icio.us (dberlind ) Me on LinkedIn Plaxo (davidberlind) Disqus (DavidBerlind) Google Profile (David.Berlind)