Downloaded 98 times
Editor's Notes
- #3 Things to mention Lots of Ruby and Rails usage in the penetration testing community (eg, Dradis, Metasploit, ronin)
- #4 1. Increasing attacks on the application layer. Examples are the automated SQL injection bots that scan the Internet, attacks on specific web applications (eg, roundcube, phpBB). Not just looking for CC numbers or personal information, sites are now getting infected to host malware (infecting your customers is probably bad business!) 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”
- #5 1. Increasing attacks on the application layer. Examples are the automated SQL injection bots that scan the Internet, attacks on specific web applications (eg, roundcube, phpBB). Not just looking for CC numbers or personal information, sites are now getting infected to host malware (infecting your customers is probably bad business!) 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”
- #6 1. Increasing attacks on the application layer. Examples are the automated SQL injection bots that scan the Internet, attacks on specific web applications (eg, roundcube, phpBB). Not just looking for CC numbers or personal information, sites are now getting infected to host malware (infecting your customers is probably bad business!) 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”
- #16 The number one security problem for all web applications is input. 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.
- #17 First question is where to do Validation 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...
- #18 First question is where to do Validation 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...
- #19 First question is where to do Validation 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...
- #20 First question is where to do Validation 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...
- #21 First question is where to do Validation 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...
- #22 First question is where to do Validation 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...
- #23 First question is where to do Validation 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...
- #24 Lots of examples of this problem available on the Internet. 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.
- #25 Lots of examples of this problem available on the Internet. 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.
- #26 Lots of examples of this problem available on the Internet. 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.
- #36 so the best way to protect your application from XSS is to filter input before it gets stored. This can be done in a number of ways 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.
- #37 so the best way to protect your application from XSS is to filter input before it gets stored. This can be done in a number of ways 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.
- #38 so the best way to protect your application from XSS is to filter input before it gets stored. This can be done in a number of ways 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.
- #39 so the best way to protect your application from XSS is to filter input before it gets stored. This can be done in a number of ways 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.
- #40 so the best way to protect your application from XSS is to filter input before it gets stored. This can be done in a number of ways 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.
- #44 One nice thing about rails is that it’s pretty hard to make a page susceptible to SQL Injection. As long as you use standard ActiveRecord syntax it will escape the parameters and avoid 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
- #45 One nice thing about rails is that it’s pretty hard to make a page susceptible to SQL Injection. As long as you use standard ActiveRecord syntax it will escape the parameters and avoid 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
- #46 One nice thing about rails is that it’s pretty hard to make a page susceptible to SQL Injection. As long as you use standard ActiveRecord syntax it will escape the parameters and avoid 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
- #47 One nice thing about rails is that it’s pretty hard to make a page susceptible to SQL Injection. As long as you use standard ActiveRecord syntax it will escape the parameters and avoid 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
- #48 One nice thing about rails is that it’s pretty hard to make a page susceptible to SQL Injection. As long as you use standard ActiveRecord syntax it will escape the parameters and avoid 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
- #49 Standard problem is that web applications are stateless 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
- #50 Standard problem is that web applications are stateless 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
- #51 Standard problem is that web applications are stateless 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
- #72 On SSL_requirement. If your site is doing the majority of its work over SSL then it’s best just to force the whole site to go over SSL and don’t have the index/login page unencrypted. This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
- #73 On SSL_requirement. If your site is doing the majority of its work over SSL then it’s best just to force the whole site to go over SSL and don’t have the index/login page unencrypted. This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
- #74 On SSL_requirement. If your site is doing the majority of its work over SSL then it’s best just to force the whole site to go over SSL and don’t have the index/login page unencrypted. This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
- #75 On SSL_requirement. If your site is doing the majority of its work over SSL then it’s best just to force the whole site to go over SSL and don’t have the index/login page unencrypted. This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.
- #76 On SSL_requirement. If your site is doing the majority of its work over SSL then it’s best just to force the whole site to go over SSL and don’t have the index/login page unencrypted. This leaves the site open to a wide range of attacks around interception of and/or re-writing of forms.