The the updated code can be found here: imedo_ci_formatter.rb

Be sure to have your input validation handle this kind of injection attacks.

In 2006 Bruce Schneier, a well known security expert, analyzed 34,000 MySpace passwords which were collected by a pishing attack. The most common of these passwords were password1, abc123, myspace1, password, blink182, qwerty1, fuckyou, 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1, and monkey.

Recently Microsoft published the results of a one year study in which Microsoft monitored automated attacks against user accounts with a fake FTP server. From the collected data they generated statistics of the most common used user names and passwords for this kind of attack. In case of passwords the top 10 consists of password, 123456, #!comment:, changeme, Fuckyou, abc123, peter, Michael, andrew, and matthew.

Both analysis underline the basic thesis of this article. Users tend to choose simple passwords which would not resist a dictionary attack and the bad guys are aware of this vulnerability and try to exploit it.

From their analysis Microsoft derived three basic hints which should be remembered when choosing a password. These hints should be presented to users of web applications during signup.

1. Use a combination of letters, numbers and special characters. Also, remember that some dictionaries used in attacks have a “l33t” mode, which allows common letter/number-to-special character substitutions (like changing a-@, i-1 ,o-0 and s=$, for example, password = p@$$w0rd). Therefore, mix them in different ways so that they are not predictable.
2. Use a combination of upper and lower case letters.
3. Make it lengthy. A longer password does not necessarily mean it is strong but it can help in some cases.

Bruce Schneier recommends to write passwords down and keep them with your valuable things in e.g. your wallet, since passwords which are not based on a dictionary are hard to remember. But remember to change them like you cancel your credit card in case you lose your wallet.

One of the features I love about TextMate, catered for in most bundles, is the ability to execute a script and get a nice pop-up window displaying the results. Scrolling through my installed language bundles, I see they all have a “Run Script” command. All, that is, except my second favourite language – Javascript. You fancy rectifying this? You fancy giving Javascript some TextMate/V8 lurv? Then walk this way …

First, lets grab V8. We’ll be using scons to build it. Scons? Aren’t they a strange  muffin-like concoction originating in the fair British Isles? That’ll be ‘scones‘ you’re thinking of. Scons is a software construction tool written in Python. Check it out at here. It must be good – Zed likes it. Install with macports.

And on with the build.

Get v8:

$> svn co http://v8.googlecode.com/svn/trunk v8
- or -
$> git clone git://github.com/v8/v8.git v8
…
$> cd v8
$> scons

The build should have been successful. V8 comes with a shell which we’re going to use. Build like so:

$> g++ ./samples/shell.cc -o v8-shell -I include libv8.a

Make sure that ‘v8-shell’ is in your PATH. And now for the final step. In TextMate: Bundles > Bundle Editor > Show Bundle Editor. Scroll down to the Javascript bundle and Create a new Command. We’ll use our imagination here and call it “Run Script”. In the Edit Command Window:

Save: Nothing
Command(s):


$(type -p "${TM_RUBY:-ruby}") -e'
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/executor"
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/save_current_document"
TextMate.save_current_document
TextMate::Executor.make_project_master_current_document
TextMate::Executor.run("v8-shell", ENV["TM_FILEPATH"])'


Input: Entire Document
Output: Show as HTML
Activation: Key Equivalent > Cmd+R
Scope Selector: source.js

This is copied and adapted from the “Run Script” Command for the Ruby bundle.

And that – as they say – is that. Time to check it out:

Open a new window in TextMate and type the following:

function addSomeValues (first, second) {
return first + second;
}

print(addSomeValues(2,3))

Select the Javascript scope. Wait for it … Ready? … Go Cmd+R! Hopefully you saw the number five.

Now change the last line to read

print(addSomeValueCATsaTOnKeyboArD(2,3))

Run again and you should get a nice ReferenceError.

Thanks go to gs over at StackOverflow for this post detailing the steps for getting the v8 shell built.

first install it:
gem install smusher

then crush your images automatically using the PunyPng service, which is currently delivering the best results in terms of file size:
smusher * --service PunyPng

Enjoy!

Finding vulnerable web servers with Shodan is as easy as using Google. Hence in combination with the Metasploit exploit framework now almost everybody is able to easily run attacks against unpatched web servers.

So, have you installed the latest security updates for your web server?

The idea behind CSRF is that an attacker sends a malicious request to the target application using a trusted connection which he expects to have been established by an innocent user. In case of web applications this could be done by hiding the request in a web page with harmless content. If the user visits the malicious web page while he is logged in to the target application in another browser tab, the dangerous request is send to the target over the trusted connection between browser and web application. Two basic scenarios are possible. In the first scenario the attacker forges a request to a commonly used web application so that it doesn’t matter who opens the malicious web page. The other scenario is to trick somebody who is known to have special privileges for one web application to open the prepared web page.

In both scenarios the malicious web page of the attacker is crafted so that it sends a hidden request to the target application. For example a HTTP GET request could be executed by using the src attribute of an img tag like in the following line of code. In this case it would delete one user account.

<img src="http://victim.example.com/user/destroy/1" />

Another possibility to hide a request in a web page is displayed in the next example. It’s a hidden HTTP POST request which changes the name and email address of the logged in user. It sends the request automatically on page load. With the changed email address the attacker can use the “forgot password?” function in order to receive a newly generated password and capture the account.

<SCRIPT>
  function SendAttack() {
    var form = document.createElement("form");
    form.style.display = "none";
    this.parentNode.appendChild(form);
    form.method = "POST";
    form.action = "http://victim.example.com/profile.php";
    form.first_name = "Bad";
    form.last_name = "Guy";
    form.email = "attacker@example.com";
    form.submit();
  }
</SCRIPT>
<BODY onload="javascript:SendAttack();"></BODY>

These two examples demonstrate that HTTP GET as well as HTTP POST are vulnerable by CSRF. Hence it is not enough to allow only POST requests to alter data. Other measure need to be applied, too. An obvious client-side countermeasures is to use separate browsers for surfing and administration, but Rails provides a server-side measure as well. The method protect_from_forgery() automatically inserts a security token in all forms and Ajax request generated by Rails. The token is calculated from the current session and the server-side secret. If the session storage is not CookieStorage the secret needs to be passed as option to the method. If an attacker is trying to send a request without the valid token to the application an ActionController::InvalidAuthenticityToken error is raised.

In Rails versions newer than 2.0 protect_from_forgery() is called for all HTTP POST requests by default. Hence it only has to be taken care of that HTTP GET  and HTTP POST requests are used appropriately (see W3C checklist) and that this is enforced. For assuring that actions are only called by HTTP POST requests Rails provides the verify() method which can be added to a controller as demonstrated in the following example. It is also shown how to define actions which should be callable by other HTTP methods than POST with the except option.

class MyController < ApplicationController
  verify :method => "post", :except => :index
end

In older Rails versions the protect_from_forgery() method can be used like shown in the following lines of code. In this example CSRF protection is disabled for the index action.

class MyController < ApplicationController
  protect_from_forgery :except => :index
end

For further information on cross-side request forgery see www.cgisecurity.com/csrf-faq.html.

XPath matchers can be combined with CSS-selector matchers. This is really useful if not, for example, the content of an element should be matched but the element itself like in the following example. Here a form is used to display data as default value in its input elements. This can be the case in web applications in which data should be edited easily without additional clicks.

<div id="content">
  <form>
    Label 1: <input id="entry_1" name="entry[1]" value="Entry 1"/>
    Label 2: <input id="entry_2" name="entry[2]" value="Entry 2"/>
    <input type="submit">
   </form>
</div>

Matching the default values of input elements with Webrat can look like the following lines of code. It is a nested combination of CSS-selector and XPath matching in order to have a readable error message if the actual output differs from the expected.

response.body.should have_selector("#content") do |content|
  content.should have_tag("form") do |form|
    form.should have_selector("#entry_1") do |input|
      input.should have_xpath("@value") do |value|
        value.should contain("Entry 1")
      end
    end
  end
end

XPath matchers are currently not support by Webrat’s within() method and therefore cannot be used to limit the area on a web page where an action should take place, e.g. clicking of a link. They can only be used for evaluating the response of an action.