Much better link. As in, it actually has links to the source code. Who wrote the OPs article and didn't both including a link to this page? The genius of some people...
I could be mistaken but I think that was added. I didn't see it the first time. I've learned to look for "via" links due to Engadget.
Has no one told them the importance of using contextual links rather than links like <a href="#">Click here</a> to download awesome-crap-0.0.1.zip. This is almost as annoying as when they have links that just link to a self-site-search for the term.
seems like some sort of content farm: the ads, the automatic linking of the words "source code" to a bing search page for the phrase "source code", etc.
It sounds like something that could be re-implemented in {Perl,Python,Ruby,Java} in a matter of minutes. It's just randomly spamming a carefully crafted cookie that will crash FireSheep.
This doesn't seem like a good idea if it works as described in the link (i.e. flooding the network). Not only is it not fixing the real underlying problem, it will probably cause additional problems like network congestion and/or destruction.
From your blog: "Sending out lots of random data, especially over a wireless network, can disturb everyone else on the network and result in their connections becoming slow and/or unreliable. In addition, FireShepherd by default sends all this data out over the Internet to www.facebook.com, placing unnecessary load on their servers."
Your position is laughable at best - you're saying "but think of the users" (you're lagging their connections) and "think of the facebook" (you're wasting their resources) when your own software treats both parties far worse at least in the short term.
Suggesting that an HTTP GET set twice a second to a server that will return a 404 will somehow have a measurable effect on the performance of a public network like a starbucks hotspot is beyond ridiculous. Since a days worth of that traffic would be dwarfed by a single user playing a single 5 second low quality youtube clip - the evidence suggests you either lack a fundamental understanding of practical networking or you're simply trying to trick people into disliking a tool (that attacks your tool).
As far as your concern about facebook's resources, it seems highly disingenuous in light of the fact that your tool automatically makes a series of two or more http requests (that generate real, dynamic responses) to any site (including facebook) you include a handler for any time it sees a new session on the wire. Without any consent, including hijacked session cookies, even if the firesheep user never once clicks to hijack it.
You have every right to release whatever wannabe click2pwn tools you want. You even have a fair point about session infrastructure, though you made it with all the subtlety of a wrecking ball.
You just look like an idiot, though, when you try cry about someone else's tool claiming injury to the very users and sites your own tool victimizes.
You should grow a much thicker skin if you want to play big boy security researcher.
(But looking at the code, all this thing does is reimplement wget poorly. It sends an HTTP request to a hard-coded "random facebook server" with a confusingly-long Facebook cookie. That's it, that's all it does. Firesheep may have an input validation issue in the current version, but that is a correctness issue that will be fixed immediately. Then this thing does nothing.)
Similar idea to FireShephard: "BlackSheep, also a Firefox plugin is designed to combat Firesheep. BlackSheep does this by dropping ‘fake’ session ID information on the wire and then monitors traffic to see if it has been hijacked. While Firesheep is largely passive, once it identifies session information for a targeted domain, it then makes a subsequent request to that same domain, using the hijacked session information in order to obtain the name of the hijacked user along with an image of the person, if available. It is this request that BlackSheep identifies in order to detect the presence of Firesheep on the network. When identified, the user will be receive [a] warning message:"
14 comments
[ 2.9 ms ] story [ 35.8 ms ] threadHas no one told them the importance of using contextual links rather than links like <a href="#">Click here</a> to download awesome-crap-0.0.1.zip. This is almost as annoying as when they have links that just link to a self-site-search for the term.
Ugh.
Your position is laughable at best - you're saying "but think of the users" (you're lagging their connections) and "think of the facebook" (you're wasting their resources) when your own software treats both parties far worse at least in the short term.
Suggesting that an HTTP GET set twice a second to a server that will return a 404 will somehow have a measurable effect on the performance of a public network like a starbucks hotspot is beyond ridiculous. Since a days worth of that traffic would be dwarfed by a single user playing a single 5 second low quality youtube clip - the evidence suggests you either lack a fundamental understanding of practical networking or you're simply trying to trick people into disliking a tool (that attacks your tool).
As far as your concern about facebook's resources, it seems highly disingenuous in light of the fact that your tool automatically makes a series of two or more http requests (that generate real, dynamic responses) to any site (including facebook) you include a handler for any time it sees a new session on the wire. Without any consent, including hijacked session cookies, even if the firesheep user never once clicks to hijack it.
You have every right to release whatever wannabe click2pwn tools you want. You even have a fair point about session infrastructure, though you made it with all the subtlety of a wrecking ball.
You just look like an idiot, though, when you try cry about someone else's tool claiming injury to the very users and sites your own tool victimizes.
You should grow a much thicker skin if you want to play big boy security researcher.
(But looking at the code, all this thing does is reimplement wget poorly. It sends an HTTP request to a hard-coded "random facebook server" with a confusingly-long Facebook cookie. That's it, that's all it does. Firesheep may have an input validation issue in the current version, but that is a correctness issue that will be fixed immediately. Then this thing does nothing.)
Similar idea to FireShephard: "BlackSheep, also a Firefox plugin is designed to combat Firesheep. BlackSheep does this by dropping ‘fake’ session ID information on the wire and then monitors traffic to see if it has been hijacked. While Firesheep is largely passive, once it identifies session information for a targeted domain, it then makes a subsequent request to that same domain, using the hijacked session information in order to obtain the name of the hijacked user along with an image of the person, if available. It is this request that BlackSheep identifies in order to detect the presence of Firesheep on the network. When identified, the user will be receive [a] warning message:"