CSC/ECE 517 Fall 2014/ch1a 23 ss: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 13: Line 13:
==Cookie Management==
==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
Hence programmers should not store sensitive data in cookies.  
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.  
[[File:cookie_sniffing.png]]
 
The fix is
The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.
 
[[File:cookie_sniffing.png|frame|Figure1: Sniffing Traffic]]
 
 
===Use SSL ===
===Use SSL ===
SSL prevents the attacker from sniffing the cookie from the network.
SSL prevents the attacker from sniffing the cookie from the network.

Revision as of 16:34, 18 September 2014

Security Features in Rails 4.x

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

Ruby on Rails, or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

Threats Against Web Applications

Cookie Management

Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name. More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.

Figure1: Sniffing Traffic


Use SSL

SSL prevents the attacker from sniffing the cookie from the network. config.force_ssl = true

New Session Identifier

Configure Rails to issue a new session identifier and declare the old one invalid after a successful login. This prevents "Session Fixation".

Timeout Cookies

Set the expiry time stamp of the cookie to a small value.

Injection

An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Cross Site Scripting (XSS)

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

Input to be sanitized:

<%= sanitize '<img src=x onerror=prompt(1)>' %>

Sanitized output:

<img src=“x”>

SQL Injection

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

Mitigation here.

Ajax Injection

Header Injection

Cross Site Request Forgery (CSRF)

This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.

Security Token

All non GET request should use a security token.

Redirection

File Upload

User Security Policies

Password Protection

Good passwords

Brute Force attack

CAPTCHAs

Security Enhancements

CSRF via Leaky #match Routes

Regular Expression Anchors in Format Validations

Clickjacking

User-Readable Sessions

Automated Security Scanners

http://brakemanscanner.org/docs/introduction/

Unresolved Issues

Verbose Servers Headers

Binding to 0.0.0.0

Versioned Secret Tokens

Logging Values in SQL statements

Offsite Redirects

Reference

http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html


<references />