"In the description, I explained how to exploit the infamous "1-Click" feature, causing victims to purchase items of my choosing without their knowledge or consent"
No not "framing" as in "iframe", but as in framed for a crime.
Slashdot points to a dailyrecord.com article where Google and MSN search history, obtained from the suspects computer(s), was used as strong forensic evidence in a murder investigation. Prosecutors say the defendant, searched for "How To Commit Murder," "instant poisons," "undetectable poisons," "fatal digoxin doses," and gun laws in New Jersey and Pennsylvania. Not good. From a web application security perspective here's where it gets interesting. Check out a snippet from the article:
"Jennifer Seymour, who worked for the State Police digital technology unit, testified this morning how she examined the digital contents of computers and hand held devices obtained as part of the investigation.
Her testimony was the strongest evidence yet in the state's circumstantial evidence case against the 34-year-old McGuire, who allegedly murdered her husband with a .38 caliber weapon, dismembered his body and placed body parts in three suitcases found in the Chesapeake Bay in May of 2004."
Catch that? "strongest evidence yet in the state's circumstantial evidence case".It’s conceivable that if someone wanted to try and frame you for a crime like the one described, its pretty easy to forge the same forensic evidence, then go out and commit the crime. The much discussd Cross-Site Request Forgery (CSRF) attack makes it trival for someone to force your browser to make a request you didn't intend to make. Even seeding Google and MSN with undesirable search phrases. For example if I really wanted to, I could have loaded in these IMG SRCs on this page upon loading.
<* img src="http://www.google.com/search?hl=en&q=How+To+Commit+Murder">
<* img src="http://www.google.com/search?hl=en&q=instant+poisons">
<* img src="http://www.google.com/search?hl=en&q=undetectable+poisons">
<* img src="http://www.google.com/search?hl=en&q=fatal+digoxin+doses">
Your browser, your ip, your search. All roads point back to you. Have a nice day.
P.S. Then again, now that my blog has these odd terms it it, I might be considered a phishing website by this time tomorrow. :)
8 comments:
A little HTTP Referer header in Google's logs might give away that some trickery was afoot, and it might even reveal the framer.
On a random note, I just noticed that the Referer: in the HTTP header is actually a misspelling of the word referrer.
--Drew
@drew, good point. Provided Google or whomever stores that data and provides it upon subpoena. Then again, nothing a little Flash trickery can't take care of either.
Write-up by Amit Klein: "Forging HTTP request headers with Flash"
http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html
And if that doesn't work, there are some need referer scrubbing browser tricks that still work.
"referer" has been spelled that way since the first HTTP RFCs specifying protocol and User Agent interaction. Hence the header spelling you see.
re: HTTP Header nonsense:
Again, making "security decisions" about trivially forgable, client-side controlled properties is a bad idea, no mater how you caveat it. Half the time these tail-wagging-the-dog measures wind up introducing their own security holes. :)
Cheers
-ae
Come on guys - I bet it's very very rare that prosecutors actually subpoena Google logs. They're just going to look through the person's history and other info that the browser stores on the hard drive and have someone testify to what was found: they don't need to connect the dots back to the web server.
This brings up another point, though - a bunch of CSRF-loaded pages via img tags aren't likely going to show up in a browser's history or saved form fields (but maybe the local cache?).
"Come on guys - I bet it's very very rare that prosecutors actually subpoena Google logs."
I don't know about Google, but when I worked at Yahoo, those type of subpoenas were being served in large quantities. Its more common one that might initially believe. And not just for criminal cases, but for civil as well.
"This brings up another point, though - a bunch of CSRF-loaded pages via img tags aren't likely going to show up in a browser's history or saved form fields (but maybe the local cache?)."
I haven't testing directly, but you could try hidden iframes or pop-under windows to get the desired effect.
"Chris Shiflett (OmniTI) blogged a CSRF issue in Amazon after a year of waiting in vien for a fix to go in"
C'mon, Jeremiah - this sounds like high school revisited. Isn't it amazing that someone could keep some gossip about someone else such a big secret for so long. Ohh, so patient.
The risk goes up, plain and simple.
Pete
Just as a side note there are couple of ways to send someone to a page in a hidden way without referrers.
As you mentioned flash is a way to do it but definitely hardest way to do it. Simple javascript can handle it.
Dan Boneh here at the Security Workshop is giving a talk on "Transaction Generators: Rootkits for the Web". I'm not sure if he's aware of the term CSRF, but I can ask.
His group has proposed SpyBlock as a possible countermeasure:
crypto.stanford.edu/SpyBlock
~L
Post a Comment