New Digg Feature = Friend Spamming: Proof of Concept
|
|
Update: Ive added like 200+ friends. This is ridiculous.
– Story Buried at 46 Diggs. Hmmm. Who would have thought? Maybe they wouldn’t be able to handle the #of friend requests if it had hit the front page…
– Here is my Befriended List
– You have to be logged in to Digg for the exploit to work
In what has got to be the stupidest move in the history of community features, Digg has created a URL-powered friend-adder. Basically, all you have to do is visit the url http://digg.com/invitefrom/{username} such as http://digg.com/invitefrom/russvirante and you automatically add them as your friend if you are currently logged in to Digg.
So, why is this royally stupid? Why should the inventor / everyone who thought this was a good idea go home for a long, long, long vacation?
<iframe src="http://digg.com/invitefrom/russvirante" height="1" width="1"></iframe>
The proof? I have inserted this code into my page. In about 5 minutes, go check your friends list and say hello to your newest buddy. And then delete me: at least there is a friend remove tool
The simple solution: Add a captcha to the landing page to verify that the user wants to add you as a friend. Come on guys, its not hard to avoid this type of spam.
No tags for this post.24 Comments
Trackbacks/Pingbacks
- Meet your newest Digg friend :: Now I Have a Blog Too - [...] me! Well, at least if you’re signed into Digg, it is. As reported at TheGoogleCache, all you have to…
- You’re Crazy if You Use Digg’s New Friend Invite Feature » 10e20 - Search, Design & Social - [...] I was writing this I came across this post by Russ Virante where he wrote a quick line of…
- Living in the Whine Country » Archive » Digg Friend Spamming - [...] [TheGoogleCache] [...]
- Digg Friend Exploit at busin3ss.name » spam 2.0 - [...] just found this here. In what has got to be the stupidest move in the history of community features,…
- Semantic Wave - Digg, Please Listen to What Jack Has to Say... Jack has explained why Digg should not be performing data-altering…
- POST is not enough to prevent CRSF vulnerability, a proof with Reddit « Inane ramblings in the programming landscape - [...] ItÂÂ seemsÂÂ thatÂÂ diggÂÂ hasÂÂ aÂÂ poorlyÂÂ thought-outÂÂ featureÂÂ :ÂÂ aÂÂ simpleÂÂ GETÂÂ requestÂÂ toÂÂ aÂÂ particularÂÂ URLÂÂ canÂÂ…
- Diggs URL-basierter Friend-Adder - Webmaster & SEO Blog - [...] auf thegooglecache // 13 x [...]
- Coding Horror at Digg | Internet Marketing Blog - [...] a result of a mistake made by developers at Digg, not only did the site inadvertently create a flaw…
- XSS Hole in Reddit Allows Gaping Access: Proof of Concept - [...] Digg added a new feature that allowed users to invite and add friends more easily. Unfortunately, as I reported…
- Stumbleupon Cross-Site Scripting Vulnerability - [...] I have previously identified XSS and/or CSRF vulnerabilities in both Digg and Reddit, Stumbleupon has largely remained innocuous to…
- Coding Horror at Digg | Search Engine Journal - [...] As a result of a mistake made by developers at Digg, not only did the site inadvertently create a…
Submit a Comment
Wow. Is this some sort of half implemented feature that got deployed? That is silly…
Good lord! I feel violated.
Yep, stupid move found. Digg has turned to crap over the past few months. They leave their self vulnerable to exploit and then do stuff that hurts the community as a whole.
Some of the users aren’t the sharpest knives in the drawer, if you know what I mean. I’m seriously thinking of blocking all digg.com traffic to my site.
GAH! When will people learn that GET should not perform an action?
Time for some civil unREST.
Here’s a list of everyone who’s befriended him:
http://digg.com/users/russvirante/friends/befriended
Perhaps you could demonstrate the security implications of this by correlating a couple of digg user-names to the IP addresses of their users. Obviously ask their permission before posting it, but I think it would highlight why its essential Digg fix this ASAP.
And now this story has been buried. I wonder if that was due to actual buries or a direct action taken by Digg staff.
Actually, thinking about it, your probably getting too many hits right now to make that viable… if a page were getting fewer than, say, a hit a minute, it would be a simple matter to correlate the IP of the page view to the new friend on digg.
Brock,
I think its safe to assume that at least some of those ppl are real digg friends (whatever your interpretation of a digg friend is) rather than people who visited this page.
No; the real issue is that GET requests — with data embedded in URIs — shoud never change server state. See sec. 9.1 of rfc 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
” In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.”
The clear way this should be done, and has been done since the beginning of the web, is to use a POST request. You should have to press a button to make a change; clicking links should always be safe. the RFC goes on:
“Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. ”
This is exactly the situation you describe and exploit. People retrieving the suspect URI in the process of loading your page make no agreement to change state on digg.com.
Every Web designer and programmer should know these simple rules, but I see them violated far too often. Consider the “click this link to confirm” links sent out in emails. The good ones will load a page that asks you to make a POST request.
CAPTCHAs are designed to prevent automated actions. Since the users are already logged in, this is likely not necessary but may still be desierable. Certainly, it doesn’t hurt. The key, though, is the request method.
Consider what happens when bots spider a site. If you allow state changes from GET requests, you’re leaving yourself open to trash coming in from people and bots who are just visiting.
Sure, but I didn’t say that it was a list of everyone who’s fallen for the trick 🙂
Bollocks to Digg. I assume someone has submitted this to reddit, delicious, newsvine etc?
Actually, you don’t even to be already logged in. If I keep this page open, open a new tab and then log on to digg it still works.
I was just thinking to myself that they oughtta sack the person responsible for this, but… it appears that Kevin Rose himself announced the feature on his blog.
http://blog.digg.com/?p=70
You’d have thought he’d check that anything baring his name wasn’t defective by design…
Yeah, this is exactly why I started using Plime.com and Reddit and moved away from Digg. It’s smaller and isn’t subject to the same kind of constant exploits.
http://www.plime.com/
http://www.reddit.com/
I’m really surprised Kevin Rose didn’t realize that would happen.
haha RTFM
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
captcha’s are super annoying. A simple solution would be to make sure the refering page was from digg. But the best solution would be to require the request to be a post in order to add the friend.
post doesn’t fix it
Wow Russ, you’re going to turn into this into a Shoemoney/MyBlogLog type battle. I hope Digg doesn’t ban you from the service like they did for him 😉
It could also just break frames. Then the person will know someone tried to add them as a friend.
Doesn’t look like it works anymore.
I think digg has caught on to this pseudo security flaw already.
You just need to add a little onload javascript to the iframe to click the button for you now. An interesting idea.
Hoping to get some advice here. So yesterday our not-for-profit, advertising free, product free, blog (focused on bizarre animal stories http://www.zooillogix.blogspot.com) found itself banned from Digg. All of our posts were removed from Digg. When my brother or I try to login, we receive the message Sorry – bad IP address. When others try to Digg our posts, they receive the message URL Blocked. This URL has been widely reported by users as being regularly used to spam Digg’s submission process and cannot be submitted at this time. This is news to us. We submit our posts to Digg, but do so only once. Digg has not responded to any of our polite requests for information or explanation. Is there any recourse for us here? We really valued our Digg audience.