Tag: iframe

Posted on

Drive-by Download: Where Network Security Meets WebAppSec

DEMO

This post was due since the Bank of India hack incident, and was fueled by PDP’s Drive-by Java post, which is a very simple, yet a well thought of extension (sort of) to the Drive-by Download attack. This post is aimed to provide a clearer understanding of the Drive-by Download attack (via a demo).

Citing Wikipedia, Any download that happens without knowledge of the user can be referred to as Drive-by Download (DBD). Pretty obviously, an attacker downloads (or uploads, depending on the perspective) malwares, viruses etc., especially in case of a zero-day. Now, I should also specify that by the sub-title “network security meets web application security”, I simply wish to point that viruses, malwares, worms are not really a concern of WebAppSec. Please note that these exclude the Javascript payloads.

Here is the video of Bank of India Hack, showing DBD in action.

Here is my demo of DBD in action.
All files downloaded to your system are 0 (zero) KB and are completely harmless. You’ve my word. 🙂

Posted on

The Web is Broken

Update: I somehow managed to make a blunder. A part of slide no. 12 was taken from David Kierznowski’s (of GNUCitizen and Blogsecurity group) presentation for OWASP Belgium Conf. I missed out on mentioning David’s name in the credits. Apologies David. I’ve updated and re-uploaded it.

Yesterday, I presented my first Webinar (Seminar on Web). It was titled, The Web is Broken -Why every feature is, in fact, a loophole. A great experience.

Although after listening to my own recording, I felt that a number of things went wrong (mostly because of problems in connectivity and slow internet speed). The issue I was worried about was that it was targeted at developers with beginner to intermediate level knowledge of web, but the topic was very broad. Fortunately, I received some good feedback along with requests to conduct more such sessions. The talk was scheduled for 1.5 hours, but it stretched for 2.5 hours.

Here is the presentation:

I hope you like it too. 🙂

Posted on

NoScript: For Guaranteed Protection From Evil IFrames

I know, I know… the title sounds like a cheap promotion ad. 😀

As I mentioned in my previous entry that Giorgio has addressed our (mine and Gareth’s) request to block iframes using NoScript. I must, however, admit that I did not expect it to be this fast. NoScript 1.1.7.1 (SilverNight) is here. The changelog has a mention to the thread which I started at Slackers (And our names).

Please note that the mozilla site may not be updated immediately. So, if you are restless soul like me, get it directly from the NoScript site.

Further, I am currently evaluating some security scanners for my company. I am little dis-heartened that there isn’t any amazing scanner available yet. However, I am very hopeful about w3af. I’ve this strong feeling that it has the potential to be the next “Metasploit Framework for www”. Expect an entry on w3af (and may be OWASPs LAPSE plugin).

Posted on

IFrames – To be or not to be?

Update: Aah. It’s not that there couldn’t have been any better news :P, but today’s News is that Ma1 has agreed to provide feature to block frames through NoScript from the next version (1.1.7). NoScripts Rocks. 🙂
Oh and Yes! Ma1 Rocks too …;)

I have been pretty busy since the last few weeks (and this trend is likely to continue for the coming weeks). Thus, my posts have been more of “news-flashes”. Apologies for that. I’ve now decided to blog about things/technologies I am working on. (Expect some write-ups on security scanners like w3af and code auditing tools like LAPSE.) However, I couldn’t stop myself from putting forward this debate on IFrames. First, let’s see what are the *evil* things that IFrames can do for… *cough*… you

CASE-I
A couple of days ago, Bank of India site was compromised. It was serving malwares to the visitors. This was done by “drive-by downloads“. The criminals were (invisible) IFRAMES.

CASE-II
I hope most of you are aware how dangerous Javascript can be. Of course, I am referring to XSS attacks. However, the recent research, notably from Jeremiah Grossman, RSnake and Gareth Hayes, showed another shockingly dark side of XSS with CSS (yes, Cascading Style Sheets 🙂 ). The criminals here are IFrames, visited attribute, etc.

CASE-III
Gareth also gave a proof of concept on his blog to perform CSRF using CSS, even when Javascript is disabled. He (very wisely) used CSS to change the LOOK and FEEL of a Submit button to a link. Now, when a *smart* user is surfing the web with javascript disabled, he’d not worry about clicking a link, and may end up clicking on the *link* to submit the form.

CASE-IV
You decide… :).
I have anyways left some other known issues, I think.

Gareth has been preaching the evil nature of IFrames for quite some time now. Yesterday, he made a new entry titled “IFRAMES ARE EVIL” on his blog. He suggested using some attributes/tags to disable/enable iframes etc. Iframes have been on my mind for quite some time. I believe that Content Restriction, once introduced, can solve a number of issues. Till then, I believe, Maone’s NoScript can come to the rescue by proving optional feature to disable iframes. I know, this is definitely not a attractive suggestion, but who knew we’d have to browse with Javascript disabled!

Moreover, I thought it’d be a good opportunity to see what other researchers have to say about it. So, I posted it to the Slackers forum. I am watching keenly. 🙂