nbpoole

Because it doesn't. The attack involves using a bug in IE (an iframe will render cookie data from the local computer) with clickjacking to steal cookie information. Sniffing on port 445 is only mentioned in the context of figuring out the username of your target (by causing the target to connect to your SMB server, running on port 445).

I'd suggest you go back and re-read the whole page before making sweeping generalizations.

1. It's used in a ton of web applications. It's slightly less popular than in the past due to the influx of frameworks like Rails and Django, but a lot of major web software (Wordpress, Drupal, Joomla, MediaWiki, phpBB) still uses it.

2. People tend to write very insecure PHP code, especially when they fail to use a framework. Again, this is slightly less true now than it was in the past. However, it's very common to see bad practices like:

- SQL queries generated via string concatenation

- Output escaping done manually, on a per-element basis, rather than in an automatic, context-sensitive manner.

- File upload scripts that let you upload PHP files, or file download scripts that accept a filename but don't sanitize against directory traversal attacks.

tptacek has a list of books on Amazon, linked to from his news.yc profile, which cover a wide range of application security topics (http://amzn.to/cthr46). I own The Art of Software Security Assessment and The Web Application Hacker's Handbook and I can vouch for them as quality resources, although I'm not sure how accessible they would be for a beginner.

In terms of a more practical introduction, Google Gruyere is an application deliberately built with security vulnerabilities for the purposes of learning (http://google-gruyere.appspot.com/). There are plenty of other projects along those lines: WebGoat is another good example.

https://twitter.com/#!/superevr/status/73920079921815552

http://bugs.developers.facebook.net/show_bug.cgi?id=9777#c66

So, the problem is framebusting code not playing well with iframes. ;-)

The automatic update process will also work if the webserver has write permissions on the files (which is a bad idea in the first place). But if it doesn't and you can't/won't give it FTP credentials for a user that does, you do need to go through a somewhat manual process.

Personally, I use vendor branching (http://svnbook.red-bean.com/en/1.1/ch07s05.html) in both SVN and Git in cases like this. I don't have to rely on the developers to generate a patch: I get all of the changes pulled directly from my local repository.

"According to Grubb, security expert Christian Heinrich demonstrated in front of the delegates how he had managed to acquire privacy-protected photos of the wife of fellow conference speaker Chris Gatford, who is Director at HackLabs."

Isn't it more likely that the police are investigating charges against Heinrich in relation to the presentation?

I should also mention that merely allowing uploads via php.ini is not an issue: you need to be storing them somewhere web accessible. A good rule of thumb for this: if you could put a PHP script in the uploads directory and have it execute, you have a potential problem.

Edit: You need to copy the try_files line into the PHP location block. I'd recommend using the following line (I just added =403 to the end of yours, so you return a 403 error rather than a 500 error when try_files fails):

   try_files $uri $uri/ /index.php?$query_string =403;

    <input type="text" value=`asdf` />

PHP's htmlspecialchars function, which is called out specifically in this post, is actually fine for most use-cases. If you write code like this:

    <input type="text" name="foo" value="<?php echo htmlspecialchars($_GET['bar']) ?>" />

The real takeaway here can be found in the middle of the post: "you must be aware of the context in which you’re working with user input."

As Lanzaa pointed out here, encryption without identity validation is worthless. If anyone can MITM your connection without you knowing about it, your encryption isn't doing you any good. That being said, there is certainly value to the "SSH model", where you verify the destination's fingerprint the first time you connect and any time it changes. That at least gives you the opportunity to know if someone is attacking you.

Take an example from earlier today: there's a vulnerability in Exim that can allow arbitrary remote code execution (http://www.vupen.com/english/advisories/2011/1185). For anyone who doesn't know what Exim is, I refer you to Wikipedia (http://en.wikipedia.org/w/index.php?title=Exim&oldid=421...):

"Exim is a mail transfer agent (MTA) used on Unix-like operating systems. Exim is free software distributed under the terms of the GNU General Public License, and it aims to be a general and flexible mailer with extensive facilities for checking incoming e-mail.

...

A large number of Exim installations exist, especially within Internet service providers[1] and universities in the UK. Exim is also widely used with the GNU Mailman mailing list manager, and cPanel."

Edit: Pull request created. https://github.com/jmathai/twitter-async/pull/108

- Found the following issue for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=305692

- Found the following issue for Chrome: http://code.google.com/p/chromium/issues/detail?id=6888

Edit: Just tested again on Windows 7. Pasting javascript:alert(1) caused the javascript: part of the URI to be stripped.

Two thoughts:

1. Disabling Javascript execution via the address bar is not something Facebook is capable of doing, any more than a random web developer can disable your ability to view the HTML of a page. Protection at this level is up to the browser developers.

2. That being said, I believe these kinds of phishing attacks demonstrate a lack of understanding on the part of end-users regarding what javascript: URIs can do. It's hard to protect users from themselves. ;-)