Merge branch 'master' of github.com:OWASP/railsgoat into top-10-2013

app/models/benefits.rb

@@ -11,15 +11,28 @@ class Benefits < ActiveRecord::Base
  end
  
  def self.make_backup(file, data_path, full_file_name)
-    if File.exists?(full_file_name)
-     system("cp #{full_file_name} #{data_path}/bak#{Time.now.to_i}_#{file.original_filename}")
-    end
-  end
+    if File.exists?(full_file_name) 
+      silence_streams(STDERR) { system("cp #{full_file_name} #{data_path}/bak#{Time.now.to_i}_#{file.original_filename}") }
+    end  
+ end
 
 =begin 
   def self.make_backup(file, data_path, full_file_name)
     FileUtils.cp "#{full_file_name}", "#{data_path}/bak#{Time.now.to_i}_#{file.original_filename}"
   end
 =end 
+
+ def self.silence_streams(*streams)
+   on_hold = streams.collect { |stream| stream.dup }
+   streams.each do |stream|
+     stream.reopen(RUBY_PLATFORM =~ /mswin/ ? 'NUL:' : '/dev/null')
+     stream.sync = true
+   end
+   yield
+ ensure
+   streams.each_with_index do |stream, i|
+     stream.reopen(on_hold[i])
+   end
+ end
  
 end

app/views/layouts/tutorial/csrf/_csrf_first.html.erb

@@ -60,7 +60,7 @@
             <div class="accordion-inner">
               <p><b> Cross-Site Request Forgery ATTACK:</b></p>
 				<p class="desc">
-					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 <b>not</b> validate either it's 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.
+					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 <b>not</b> 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.
 				</p>
 			   	<p>
 				 <pre class="ruby">
@@ -84,7 +84,7 @@
 				
 			  <p><b> Cross-Site Request Forgery SOLUTION:</b></p>
 			  <p>
-				 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.
+				 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.
 			 </p>
 			 <p>  		
 				 Once protect_from_forgery is added back... 

app/views/layouts/tutorial/redirects/_redirects_first.html.erb

@@ -17,7 +17,8 @@
           <div class="accordion-body in collapse" id="collapseOne" style="height: auto;">
             <div class="accordion-inner">
 	  		 <p class="desc">
-              OWASP Description - Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
+              Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.
+              Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages.
   			 </p>
 	  		 <p class="desc">
               Railsgoat allows the redirection to the paths previously requested but for which the user did not have access. Following authentication, the user is redirected.

app/views/layouts/tutorial/xss/_xss_first.html.erb

@@ -84,7 +84,7 @@
             <div class="accordion-inner">
               <p class="desc">
 				Apparently we had some issues rendering people's names with weird formatting or something, I dunno, I think I fixed it by safely encoding html and rendering the necessary content.<br/><br/>
-				Your <b>Welcome</b>!
+				You're <b>Welcome</b>!
 			  </p>
             </div>
           </div>