Recomendados
Recomendados
Más contenido relacionado
Último
Último (20)
Destacado
Destacado (20)
Web Appliction Security - Scotland on Rails presentation
- 1. Web Application Security Rails & the OWASP Top-10 Rory McCune - rorym@mccune.org.uk
- 2. Background - Who am I?
- 3. Background - Who am I? IT Security Professional 14 years in IT, 9 Years in IT Security, 3 in “Ethical Hacking” I get to break into websites for a living
- 4. Why is this Important?
- 5. Why is this Important? 1. Bad guys will try to break into your applications
- 6. Why is this Important? 1. Bad guys will try to break into your applications 2. Good guys will try to break into your applications
- 7. Why is this Important? 1. Bad guys will try to break into your applications 2. Good guys will try to break into your applications 3. Depending on your industry , regulators will be interested in the security of your code.
- 8. OWASP & the Top-10
- 9. OWASP & the Top-10 OWASP - Open Web Application Security Project
- 10. OWASP & the Top-10 OWASP - Open Web Application Security Project Hosts and sponsors web application security projects
- 11. OWASP & the Top-10 OWASP - Open Web Application Security Project Hosts and sponsors web application security projects Also has a chapter organisation around the world
- 12. OWASP & the Top-10 OWASP - Open Web Application Security Project Hosts and sponsors web application security projects Also has a chapter organisation around the world OWASP Top-10
- 13. OWASP & the Top-10 OWASP - Open Web Application Security Project Hosts and sponsors web application security projects Also has a chapter organisation around the world OWASP Top-10 Listing of the “most critical” Web Application Security flaws
- 15. No Silver Bullets - “We’ve got a Firewall, so we don’t need to worry” - “We use SSL, so we don’t need to worry” - “We use a framework, so we don’t need to worry”
- 16. No Silver Bullets - “We’ve got a Firewall, so we don’t need to worry” - “We use SSL, so we don’t need to worry” - “We use a framework, so we don’t need to worry”
- 17. No Silver Bullets - “We’ve got a Firewall, so we don’t need to worry” - “We use SSL, so we don’t need to worry” - “We use a framework, so we don’t need to worry”
- 18. No Silver Bullets - “We’ve got a Firewall, so we don’t need to worry” - “We use SSL, so we don’t need to worry” - “We use a framework, so we don’t need to worry”
- 19. Public Enemy Number 1
- 20. Public Enemy Number 1 INPUT
- 22. Dealing with Input Two main approaches
- 23. Dealing with Input Two main approaches Input Validation
- 24. Dealing with Input Two main approaches Input Validation Output Normalization
- 25. Dealing with Input Two main approaches Input Validation Output Normalization Things to Think about
- 26. Dealing with Input Two main approaches Input Validation Output Normalization Things to Think about Need to deal with All inputs/outputs (form fields, cookie, headers...)
- 27. Dealing with Input Two main approaches Input Validation Output Normalization Things to Think about Need to deal with All inputs/outputs (form fields, cookie, headers...) Where to validate
- 28. Dealing with Input Two main approaches Input Validation Output Normalization Things to Think about Need to deal with All inputs/outputs (form fields, cookie, headers...) Where to validate How to validate (Black List/White List)
- 29. Specific Problems - XSS
- 30. Specific Problems - XSS “Allowing a malicious user of your application to execute scripts in other users browsers”
- 31. Specific Problems - XSS “Allowing a malicious user of your application to execute scripts in other users browsers” Very common in web applications 90%+ of sites
- 32. Specific Problems - XSS “Allowing a malicious user of your application to execute scripts in other users browsers” Very common in web applications 90%+ of sites Can have serious consequences - cookie stealing, page defacement...
- 33. Example - Rails Weblog
- 34. Example - Rails Weblog XSS in the Comment section of a popular rails weblog application
- 35. Example - Rails Weblog XSS in the Comment section of a popular rails weblog application Comment body, e-mail address,website address escaped ok with h()
- 36. Example - Rails Weblog XSS in the Comment section of a popular rails weblog application Comment body, e-mail address,website address escaped ok with h() <%= link_to_unless item.url.blank?, ((item.author || '(unknown)').slice(0,40)), item.url %>
- 37. Example - Rails Weblog XSS in the Comment section of a popular rails weblog application Comment body, e-mail address,website address escaped ok with h() <%= link_to_unless item.url.blank?, ((item.author || '(unknown)').slice(0,40)), item.url %> <%= link_to_unless item.url.blank?, ((h(item.author) || '(unknown)').slice(0,40)), item.url %>
- 38. Fixing XSS - 1
- 39. Fixing XSS - 1 Standard recommended approach
- 40. Fixing XSS - 1 Standard recommended approach Use h() function on all your views
- 41. Fixing XSS - 1 Standard recommended approach Use h() function on all your views Problem - The bad data goes into your database
- 42. Fixing XSS - 1 Standard recommended approach Use h() function on all your views Problem - The bad data goes into your database Problem - You need to remember *EVERY* time
- 43. Fixing XSS - 1 Standard recommended approach Use h() function on all your views Problem - The bad data goes into your database Problem - You need to remember *EVERY* time Safe ERB can help with this.
- 44. Fixing XSS - 2
- 45. Fixing XSS - 2 Input Validation
- 46. Fixing XSS - 2 Input Validation Loads of Options here
- 47. Fixing XSS - 2 Input Validation Loads of Options here sanitize helper
- 48. Fixing XSS - 2 Input Validation Loads of Options here sanitize helper plugin - sanitize_params
- 49. Fixing XSS - 2 Input Validation Loads of Options here sanitize helper plugin - sanitize_params plugin - xss_terminate
- 50. SQL Injection * * Comic courtesy of xkcd.com
- 51. SQL Injection * SQL Injection * Comic courtesy of xkcd.com
- 52. SQL Injection * SQL Injection Allowing SQL statements to be inserted into your application by a user. * Comic courtesy of xkcd.com
- 53. SQL Injection * SQL Injection Allowing SQL statements to be inserted into your application by a user. Potentially devastating, allow for an attacker to take over the server. * Comic courtesy of xkcd.com
- 54. SQL Injection in Rails
- 55. SQL Injection in Rails Limited problem due to use of ActiveRecord
- 56. SQL Injection in Rails Limited problem due to use of ActiveRecord Never directly insert strings into queries
- 57. SQL Injection in Rails Limited problem due to use of ActiveRecord Never directly insert strings into queries User.find(:all, :conditions => quot;name = '#{params[:name]}'quot;)
- 58. SQL Injection in Rails Limited problem due to use of ActiveRecord Never directly insert strings into queries User.find(:all, :conditions => quot;name = '#{params[:name]}'quot;) Who knew someone’s name could be ‘ OR 1=1--
- 59. SQL Injection in Rails Limited problem due to use of ActiveRecord Never directly insert strings into queries User.find(:all, :conditions => quot;name = '#{params[:name]}'quot;) Who knew someone’s name could be ‘ OR 1=1-- one other thing - Framework bugs...
- 61. Session Management Web Applications are innately stateless
- 62. Session Management Web Applications are innately stateless We use session id’s to manage this
- 63. Session Management Web Applications are innately stateless We use session id’s to manage this Problem - The Session ID needs to be secured
- 64. Cookie Store
- 65. Cookie Store Default Session handling method in Rails 2+
- 66. Cookie Store Default Session handling method in Rails 2+ Stores session on the client machine
- 67. Cookie Store Default Session handling method in Rails 2+ Stores session on the client machine Uses a signature to prevent tampering
- 68. Cookie Store - Problems?
- 69. Cookie Store - Problems? Generated some controversy when it was first released
- 70. Cookie Store - Problems? Generated some controversy when it was first released Concerns around Security of storing session client side
- 71. Cookie Store - Problems? Generated some controversy when it was first released Concerns around Security of storing session client side Actually not too much of a problem, so long as you....
- 72. Cookie Store - Problems? Generated some controversy when it was first released Concerns around Security of storing session client side Actually not too much of a problem, so long as you.... use a strong secret
- 73. Cookie Store - Problems? Generated some controversy when it was first released Concerns around Security of storing session client side Actually not too much of a problem, so long as you.... use a strong secret Don’t store anything sensitive in session
- 74. Cookie Store - Problems? Generated some controversy when it was first released Concerns around Security of storing session client side Actually not too much of a problem, so long as you.... use a strong secret Don’t store anything sensitive in session Watch out for session replay
- 75. Things to think about
- 76. Things to think about Session Expiry
- 77. Things to think about Session Expiry Set as short as practical (consider shared machines!)
- 78. Things to think about Session Expiry Set as short as practical (consider shared machines!) Transmission in the clear
- 79. Things to think about Session Expiry Set as short as practical (consider shared machines!) Transmission in the clear anyone using the conference wi-fi?
- 80. Things to think about Session Expiry Set as short as practical (consider shared machines!) Transmission in the clear anyone using the conference wi-fi? Cookie Options
- 81. Things to think about Session Expiry Set as short as practical (consider shared machines!) Transmission in the clear anyone using the conference wi-fi? Cookie Options Set Secure session cookie option
- 84. Authentication & Authorization Authentication http authentication
- 85. Authentication & Authorization Authentication http authentication restful_authentication & Others
- 86. Authentication & Authorization Authentication http authentication restful_authentication & Others Authorization
- 87. Authentication & Authorization Authentication http authentication restful_authentication & Others Authorization dealing with forceful browsing
- 89. Password Management Common Password Security Problems
- 90. Password Management Common Password Security Problems Passing in the clear
- 91. Password Management Common Password Security Problems Passing in the clear ssl_requirement
- 92. Password Management Common Password Security Problems Passing in the clear ssl_requirement Storing in the clear
- 93. Password Management Common Password Security Problems Passing in the clear ssl_requirement Storing in the clear always store hashes with Salt and Pepper
- 95. More Password Management Brute Forcing
- 96. More Password Management Brute Forcing password strength (validates_format_of)
- 97. More Password Management Brute Forcing password strength (validates_format_of) Account lockout?
- 98. More Password Management Brute Forcing password strength (validates_format_of) Account lockout? Password change forms
- 99. More Password Management Brute Forcing password strength (validates_format_of) Account lockout? Password change forms Always ask for the original password
- 100. More Password Management Brute Forcing password strength (validates_format_of) Account lockout? Password change forms Always ask for the original password Password Reset
- 101. Conclusion Rails Provides a lot of tools to help develop secure applications Doesn’t remove the need to think about this during development
- 102. More information OWASP - Ruby On Rails Security Guide, Secure Coding Guide ... (www.owasp.org) Rails wiki Blogs
- 103. Questions?
- 104. Bonus Box - How to Test Where to start OWASP Testing guide Web Application Hackers Handbook Tools Proxy (eg, WebScarab, Burp) Automation - Ronin, Metasploit
Notas del editor
- Things to mention Lots of Ruby and Rails usage in the penetration testing community (eg, Dradis, Metasploit, ronin)
- 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”
- 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”
- 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”
- 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.
- 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...
- 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...
- 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...
- 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...
- 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...
- 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...
- 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...
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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.