Web Appliction Security - Scotland on Rails presentation
by raesene on Mar 28, 2009
- 1,970 views
My presentation for the Scotland on Rails 2009 conference. There will be a video of it later which will (hopefully) make more sense also look out for related blog entries at http://www.mccune.org.uk
My presentation for the Scotland on Rails 2009 conference. There will be a video of it later which will (hopefully) make more sense also look out for related blog entries at http://www.mccune.org.uk
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 2
- Downloads
- 61
- Comments
- 0
- Embed Views
- Views on SlideShare
- 1,955
- Total Views
- 1,970
Lots of Ruby and Rails usage in the penetration testing community (eg, Dradis, Metasploit, ronin)
2. Ethical hacking is a growing industry and is largely focused on web applications. If you’re developing applications for use by large (and indeed some small) companies, they may well commission a web application security review as part of the work, which will lead to a team of testers spending about a week trying to find security flaws in your application .
3. Anyone want to process Credit Card details? if so then you need to comply with PCI-DSS which specifically requires web applications to comply with the “OWASP top-10”
2. Ethical hacking is a growing industry and is largely focused on web applications. If you’re developing applications for use by large (and indeed some small) companies, they may well commission a web application security review as part of the work, which will lead to a team of testers spending about a week trying to find security flaws in your application .
3. Anyone want to process Credit Card details? if so then you need to comply with PCI-DSS which specifically requires web applications to comply with the “OWASP top-10”
2. Ethical hacking is a growing industry and is largely focused on web applications. If you’re developing applications for use by large (and indeed some small) companies, they may well commission a web application security review as part of the work, which will lead to a team of testers spending about a week trying to find security flaws in your application .
3. Anyone want to process Credit Card details? if so then you need to comply with PCI-DSS which specifically requires web applications to comply with the “OWASP top-10”
If you take nothing else about web app security from this presentation then just take one concept . Input Validation.
95%+ (very unscientifically assessed) of all web application security problems come down to problems with unvalidated input to the application.
There are various problems with input validation, and we’ll walk through some of the more common ones now.
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
Important to note that client side is never the answer (for security). Client Side validation can be trivially bypassed by an attacker (commonly using proxy software (burp, webscarab etc)
Controller - Has the advantage of validating your data as soon as it gets server-side. Disadvantage is that it’s not well tied to the model (so you end up potentially doing the validation multiple times as data enters the application from different angles)
Model - Makes most sense, only problem is where input isn’t persisted to the database (so validation isn’t invoked)
A lot of validation will try to block “known bad” input. This is ultimately a failing strategy
1. You need to keep up to date with the bad stuff (fancy changing your application every time something new comes out)
2. The bad guys think up new ways pretty frequently (ha.ckers.org/xss.html)
White list is the right way to go...
xssed.com contains an archive of sites that are vulnerable to XSS. If you look there you’ll see a wide variety of well known sites
A lot of people think of XSS as just being something that a hacker can use to bring up a “pop up box” but if you consider the power of javascript then you’ll realise that there’s a lot more to it than that.
Examples would be site defacement, phishing attacks, and even things like port scanning.
xssed.com contains an archive of sites that are vulnerable to XSS. If you look there you’ll see a wide variety of well known sites
A lot of people think of XSS as just being something that a hacker can use to bring up a “pop up box” but if you consider the power of javascript then you’ll realise that there’s a lot more to it than that.
Examples would be site defacement, phishing attacks, and even things like port scanning.
xssed.com contains an archive of sites that are vulnerable to XSS. If you look there you’ll see a wide variety of well known sites
A lot of people think of XSS as just being something that a hacker can use to bring up a “pop up box” but if you consider the power of javascript then you’ll realise that there’s a lot more to it than that.
Examples would be site defacement, phishing attacks, and even things like port scanning.
Blacklist filtering attempts to filter “bad stuff”. Inherently unreliable as hackers (both white and black hat) are constantly finding new ways to bypass this kind of filter
Whitelist filtering. Much more reliable basically takes the approach of only allowing “known good” input.
Next choice is where to filter, in the controller or in the model. Good sense may say that this is a data issue, so the model is the best place to handle it. Unfortunately this can leave edge cases where the data which is input isn’t persisted to a model immediately, but is passed onto another view, via the controller (think preview), so I’d say controller is the best place for this kind of input validation
some plugins to help for your rails app. sanitize_params is a good one and is pretty effective, but it may cause some problems with fields that need html code.
xss_terminate is another option. It works at the model level so remember the potential for it not to be brought into play.
Blacklist filtering attempts to filter “bad stuff”. Inherently unreliable as hackers (both white and black hat) are constantly finding new ways to bypass this kind of filter
Whitelist filtering. Much more reliable basically takes the approach of only allowing “known good” input.
Next choice is where to filter, in the controller or in the model. Good sense may say that this is a data issue, so the model is the best place to handle it. Unfortunately this can leave edge cases where the data which is input isn’t persisted to a model immediately, but is passed onto another view, via the controller (think preview), so I’d say controller is the best place for this kind of input validation
some plugins to help for your rails app. sanitize_params is a good one and is pretty effective, but it may cause some problems with fields that need html code.
xss_terminate is another option. It works at the model level so remember the potential for it not to be brought into play.
Blacklist filtering attempts to filter “bad stuff”. Inherently unreliable as hackers (both white and black hat) are constantly finding new ways to bypass this kind of filter
Whitelist filtering. Much more reliable basically takes the approach of only allowing “known good” input.
Next choice is where to filter, in the controller or in the model. Good sense may say that this is a data issue, so the model is the best place to handle it. Unfortunately this can leave edge cases where the data which is input isn’t persisted to a model immediately, but is passed onto another view, via the controller (think preview), so I’d say controller is the best place for this kind of input validation
some plugins to help for your rails app. sanitize_params is a good one and is pretty effective, but it may cause some problems with fields that need html code.
xss_terminate is another option. It works at the model level so remember the potential for it not to be brought into play.
Blacklist filtering attempts to filter “bad stuff”. Inherently unreliable as hackers (both white and black hat) are constantly finding new ways to bypass this kind of filter
Whitelist filtering. Much more reliable basically takes the approach of only allowing “known good” input.
Next choice is where to filter, in the controller or in the model. Good sense may say that this is a data issue, so the model is the best place to handle it. Unfortunately this can leave edge cases where the data which is input isn’t persisted to a model immediately, but is passed onto another view, via the controller (think preview), so I’d say controller is the best place for this kind of input validation
some plugins to help for your rails app. sanitize_params is a good one and is pretty effective, but it may cause some problems with fields that need html code.
xss_terminate is another option. It works at the model level so remember the potential for it not to be brought into play.
Blacklist filtering attempts to filter “bad stuff”. Inherently unreliable as hackers (both white and black hat) are constantly finding new ways to bypass this kind of filter
Whitelist filtering. Much more reliable basically takes the approach of only allowing “known good” input.
Next choice is where to filter, in the controller or in the model. Good sense may say that this is a data issue, so the model is the best place to handle it. Unfortunately this can leave edge cases where the data which is input isn’t persisted to a model immediately, but is passed onto another view, via the controller (think preview), so I’d say controller is the best place for this kind of input validation
some plugins to help for your rails app. sanitize_params is a good one and is pretty effective, but it may cause some problems with fields that need html code.
xss_terminate is another option. It works at the model level so remember the potential for it not to be brought into play.
It is still possible to come up with problems
--
Security focus advisory on Rails
Ruby on Rails ':offset' And ':limit' Parameters SQL Injection Vulnerabilities
Ruby on Rails is prone to multiple SQL-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in SQL queries.
A successful exploit could allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
Versions prior to Ruby on Rails 2.1.1 are affected
This only applied to limited cases (where offset or limit where user settable) but demonstrates the problem
It is still possible to come up with problems
--
Security focus advisory on Rails
Ruby on Rails ':offset' And ':limit' Parameters SQL Injection Vulnerabilities
Ruby on Rails is prone to multiple SQL-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in SQL queries.
A successful exploit could allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
Versions prior to Ruby on Rails 2.1.1 are affected
This only applied to limited cases (where offset or limit where user settable) but demonstrates the problem
It is still possible to come up with problems
--
Security focus advisory on Rails
Ruby on Rails ':offset' And ':limit' Parameters SQL Injection Vulnerabilities
Ruby on Rails is prone to multiple SQL-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in SQL queries.
A successful exploit could allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
Versions prior to Ruby on Rails 2.1.1 are affected
This only applied to limited cases (where offset or limit where user settable) but demonstrates the problem
It is still possible to come up with problems
--
Security focus advisory on Rails
Ruby on Rails ':offset' And ':limit' Parameters SQL Injection Vulnerabilities
Ruby on Rails is prone to multiple SQL-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in SQL queries.
A successful exploit could allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
Versions prior to Ruby on Rails 2.1.1 are affected
This only applied to limited cases (where offset or limit where user settable) but demonstrates the problem
It is still possible to come up with problems
--
Security focus advisory on Rails
Ruby on Rails ':offset' And ':limit' Parameters SQL Injection Vulnerabilities
Ruby on Rails is prone to multiple SQL-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in SQL queries.
A successful exploit could allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
Versions prior to Ruby on Rails 2.1.1 are affected
This only applied to limited cases (where offset or limit where user settable) but demonstrates the problem
Problem is that your session ID is essentially the same as your password for the duration of the session. If an attacker steals your session ID they can impersonate you.
Session Expiry is also a problem
Problem is that your session ID is essentially the same as your password for the duration of the session. If an attacker steals your session ID they can impersonate you.
Session Expiry is also a problem
Problem is that your session ID is essentially the same as your password for the duration of the session. If an attacker steals your session ID they can impersonate you.
Session Expiry is also a problem
This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.