SlideShare a Scribd company logo

Andrews whitakrer lecture18-security.ppt

•Download as PPT, PDF•
•
S
SilverGold16

Web secure

1 of 25
1 CSE 403 Web Security Testing Reading: Andrews/Whitaker, How to Break Web Software, Ch. 2-5 These lecture slides are copyright (C) Marty Stepp, 2007. They may not be rehosted, sold, or modified without expressed permission from the author. All rights reserved.
2 Big questions  How much do I have to worry about security in my web application?  What kinds of common attacks can be performed?  What common bugs in my code lead to these flaws?  What tools do attackers use?  How can I prevent security problems in my code and (hopefully) ensure overall system security?
3 Denial-of-Service (DoS)  Denial of Service (DoS) attack: Attacker causes web server to be unavailable.  How attack is performed:  Attacker frequently requests many pages from your web site.  distributed DoS (DDoS): DoS using lots of computers  Your server cannot handle this many requests at a time, so it turns into a smoldering pile of goo (or just becomes very slow).  Problems that this attack can cause:  Users cannot get to your site.  Online store's server crashes -> store loses potential revenue.  Server may crash and lose or corrupt important data.  All the bandwidth used by the DoSers may cost you $$$.
4 Packet sniffing  packet sniffing: Listening to traffic sent on a network.  Many internet protocols (http, aim, email) are unsecure.  If an attacker is on the same local network (LAN) as you, he may be able to listen to information your computer is sending.  read your email/IMs as you send them  see what web sites you are viewing  grab your password as it's being sent to the server  solutions:  Use secure protocols (https)  Encryption  Don't let creeps on your LAN
5 Password cracking  password cracking: Guessing the passwords of privileged users of your system.  How attack is performed:  brute force attack: Attacker uses software that sequentially tries every possible password.  dictionary attack: Attacker uses software that sequentially tries passwords based on words in a dictionary.  every word in the dictionary  combinations of words, numbers, etc.  What you can do about it:  Force users to have secure passwords.  Block an IP address from logging in after N failed attempts.
6 Phishing / social engineering  phishing: Masqueraded mails or web sites.  social engineering: Attempts to manipulate users, such as fraudulently acquiring passwords or credit card numbers.  Problems:  If trusted users of your system are tricked into giving out their personal information, attackers can use this to log in as those users and compromise your system.
7 Man-in-the-middle  man-in-the-middle attack: Attacker sits between two communication endpoints and silently intercepts traffic between them.  tricks user to go to attacker's site instead of real site  intercepts sensitive information and/or modifies data before sending it from one endpoint to the other
8 Privilege escalation  privilege escalation: Attacker becomes able to run code on your server as a privileged user.  Example: Perhaps normal users aren't able to directly query your database. But an attacker may find a flaw in your security letting him run as an administrator and perform the query.  Once you're running as root, you're God. You own the server. You can do anything you want...
9 Cross-site scripting (XSS)  cross-site scripting: Causing one person's script code to be executed when a user browses to another site.  Example: Visit google.com, but evil.com's JavaScript runs.  How attack is performed:  Attacker finds unsecure code on target site.  Attacker uses hole to inject JavaScript into the page.  User visits page, sees malicious script code.
10 SQL Injection  SQL injection: An attacker causing undesired SQL queries to be run on a server's database.  Often caused when untrusted input is pasted into a SQL query  Example:  query="SELECT * FROM Users WHERE name=' + name + "';";  specify a user name of "haha' OR 'a'='a"  SELECT * FROM Users WHERE name='haha' OR 'a'='a';  Attacker can see, delete, modify your sensitive personal data!
11 Thinking like an attacker: Finding vulnerabilities
12 Panning for gold  Looking through a target application for exploits:  View Source , and look for:  HTML comments  script code  other sensitive information in code: IP addresses, email addresses, SQL queries, hidden fields, ...  watch HTTP requests/responses  look for hidden pages, files, parameters to target  error messages sent back to your browser by the app  200: OK  400: Invalid request  403: Forbidden  404: File not found  500: Internal server error
13 Input forms  Forms let users pass parameters to the web server.  Parameters are passed using GET or POST requests.  GET: parameters are contained in the request URL. http://www.google.com?q=Stephen+Colbert&lang=en  POST: parameters are contained in the HTTP packet header.  harder for the user to see, but no more secure than GET  Forms provide a rich ground for us to attack...
14 Form validation  validation: Examining form parameters to make sure they are acceptable before they are submitted.  nonempty, alphabetical, numeric, length, ...  client-side: HTML/JS checks values before request is sent.  server-side: JSP/Ruby/PHP/etc. checks values received.  Some validation is performed by restricting the choices available to the user.  select boxes  input text boxes with maxlength attribute  key event listeners that erase certain key presses
15 User input attacks  Bypassing client-side input restrictions and validation  maxlength limits on input text fields  choices not listed in a select boxes  hidden input fields  modifying or disabling client-side JavaScript validation code
16 Guessing files/directories  Many sites have reachable files and resources that are hidden from attackers only by obscurity  Try common file/folder/commands to see what happens  /etc/passwd , /etc/shadow  cat, ls, grep  guess file names based on others  page11.php --> page12.php  loginfailure.jsp --> loginsuccess.jsp  accounts/myaccount.html --> accounts/youraccount.html  brute force / web spiders  port scanners
17 Other attacks  Attacking GET parameters  Attacking hidden input fields  Attacking cookies  Injecting malicious script code (XSS)  Injecting malicious SQL queries (SQL injection)
18 Designing for Security
19 Methods of security  Security through obscurity: Relying on the fact that attackers don't know something needed to harm you.  Example: "If an attacker pointed their browser to http://foo.com/passwords.txt, they'd get our passwords. But nobody knows that file is there, so we are safe."  Example: "Our authentication database goes down for 2 minutes every night at 4am. During that time any user can log in without restrictions. But no one knows this, and the odds of a login at that time are miniscule."
20 Secure authentication  Force users to log in to your system before performing sensitive operations  Use secure protocols (https, etc.) to prevent sniffing  Force users to use strong passwords  not "password", "abc", same as user name, etc.
21 Principle of least privilege  principle of least privilege: Having just enough authority to get the job done (and no more!).  Examples:  A web server should only be given access to the set of HTML files that the web server is supposed to serve.  Code should not "run as root" or as a highly privileged user unless absolutely necessary.  Turn off unnecessary services on your web server  disable SSH, VNC, sendmail, etc.  close all ports except 80, others needed for web traffic
22 Sanitizing inputs  sanitizing inputs: Encoding and filtering untrusted user input before accepting it into a trusted system.  Ensure that accepted data is the right type, format, length...  Disallow entry of bad data into an HTML form.  Remove any SQL code from submitted user names.  HTML-encode any input text that is to be displayed back to the user as HTML or JavaScript.
23 Verifying that code is secure  Before code is written:  considering security in the design process  As code is being written:  code reviews  pair programming  After code has been written:  walkthroughs  security audits
24 Security audits  security audit: Series of checks and questions to assess the security of your system  can be done by an internal or external auditor  best if done as a process, not an individual event  penetration test: Targeted white-hat attempt to compromise your system's security  not unlike our attempts to break CSE 144's turnin page  risk analysis: Assessment of relative risks of what can go wrong when security is compromised
25 Security audit questions  Does your system require secure authentication with passwords?  Are passwords difficult to crack?  Are there access control lists (ACLs) in place on network devices?  Are there audit logs to record who accesses data?  Are the audit logs reviewed?  Are your OS security settings up to accepted industry levels?  Have all unnecessary applications and services been eliminated?  Are all operating systems and applications patched to current levels?  How is backup media stored? Who has access to it? Is it up-to-date?  Is there a disaster recovery plan? Has it ever been rehearsed?  Are there good cryptographic tools in place to govern data encryption?  Have custom-built applications been written with security in mind?  How have these custom applications been tested for security flaws?  How are configuration and code changes documented at every level? How are these records reviewed and who conducts the review?

More Related Content

Andrews whitakrer lecture18-security.ppt

  • 1. 1 CSE 403 Web Security Testing Reading: Andrews/Whitaker, How to Break Web Software, Ch. 2-5 These lecture slides are copyright (C) Marty Stepp, 2007. They may not be rehosted, sold, or modified without expressed permission from the author. All rights reserved.
  • 2. 2 Big questions  How much do I have to worry about security in my web application?  What kinds of common attacks can be performed?  What common bugs in my code lead to these flaws?  What tools do attackers use?  How can I prevent security problems in my code and (hopefully) ensure overall system security?
  • 3. 3 Denial-of-Service (DoS)  Denial of Service (DoS) attack: Attacker causes web server to be unavailable.  How attack is performed:  Attacker frequently requests many pages from your web site.  distributed DoS (DDoS): DoS using lots of computers  Your server cannot handle this many requests at a time, so it turns into a smoldering pile of goo (or just becomes very slow).  Problems that this attack can cause:  Users cannot get to your site.  Online store's server crashes -> store loses potential revenue.  Server may crash and lose or corrupt important data.  All the bandwidth used by the DoSers may cost you $$$.
  • 4. 4 Packet sniffing  packet sniffing: Listening to traffic sent on a network.  Many internet protocols (http, aim, email) are unsecure.  If an attacker is on the same local network (LAN) as you, he may be able to listen to information your computer is sending.  read your email/IMs as you send them  see what web sites you are viewing  grab your password as it's being sent to the server  solutions:  Use secure protocols (https)  Encryption  Don't let creeps on your LAN
  • 5. 5 Password cracking  password cracking: Guessing the passwords of privileged users of your system.  How attack is performed:  brute force attack: Attacker uses software that sequentially tries every possible password.  dictionary attack: Attacker uses software that sequentially tries passwords based on words in a dictionary.  every word in the dictionary  combinations of words, numbers, etc.  What you can do about it:  Force users to have secure passwords.  Block an IP address from logging in after N failed attempts.
  • 6. 6 Phishing / social engineering  phishing: Masqueraded mails or web sites.  social engineering: Attempts to manipulate users, such as fraudulently acquiring passwords or credit card numbers.  Problems:  If trusted users of your system are tricked into giving out their personal information, attackers can use this to log in as those users and compromise your system.
  • 7. 7 Man-in-the-middle  man-in-the-middle attack: Attacker sits between two communication endpoints and silently intercepts traffic between them.  tricks user to go to attacker's site instead of real site  intercepts sensitive information and/or modifies data before sending it from one endpoint to the other
  • 8. 8 Privilege escalation  privilege escalation: Attacker becomes able to run code on your server as a privileged user.  Example: Perhaps normal users aren't able to directly query your database. But an attacker may find a flaw in your security letting him run as an administrator and perform the query.  Once you're running as root, you're God. You own the server. You can do anything you want...
  • 9. 9 Cross-site scripting (XSS)  cross-site scripting: Causing one person's script code to be executed when a user browses to another site.  Example: Visit google.com, but evil.com's JavaScript runs.  How attack is performed:  Attacker finds unsecure code on target site.  Attacker uses hole to inject JavaScript into the page.  User visits page, sees malicious script code.
  • 10. 10 SQL Injection  SQL injection: An attacker causing undesired SQL queries to be run on a server's database.  Often caused when untrusted input is pasted into a SQL query  Example:  query="SELECT * FROM Users WHERE name=' + name + "';";  specify a user name of "haha' OR 'a'='a"  SELECT * FROM Users WHERE name='haha' OR 'a'='a';  Attacker can see, delete, modify your sensitive personal data!
  • 11. 11 Thinking like an attacker: Finding vulnerabilities
  • 12. 12 Panning for gold  Looking through a target application for exploits:  View Source , and look for:  HTML comments  script code  other sensitive information in code: IP addresses, email addresses, SQL queries, hidden fields, ...  watch HTTP requests/responses  look for hidden pages, files, parameters to target  error messages sent back to your browser by the app  200: OK  400: Invalid request  403: Forbidden  404: File not found  500: Internal server error
  • 13. 13 Input forms  Forms let users pass parameters to the web server.  Parameters are passed using GET or POST requests.  GET: parameters are contained in the request URL. http://www.google.com?q=Stephen+Colbert&lang=en  POST: parameters are contained in the HTTP packet header.  harder for the user to see, but no more secure than GET  Forms provide a rich ground for us to attack...
  • 14. 14 Form validation  validation: Examining form parameters to make sure they are acceptable before they are submitted.  nonempty, alphabetical, numeric, length, ...  client-side: HTML/JS checks values before request is sent.  server-side: JSP/Ruby/PHP/etc. checks values received.  Some validation is performed by restricting the choices available to the user.  select boxes  input text boxes with maxlength attribute  key event listeners that erase certain key presses
  • 15. 15 User input attacks  Bypassing client-side input restrictions and validation  maxlength limits on input text fields  choices not listed in a select boxes  hidden input fields  modifying or disabling client-side JavaScript validation code
  • 16. 16 Guessing files/directories  Many sites have reachable files and resources that are hidden from attackers only by obscurity  Try common file/folder/commands to see what happens  /etc/passwd , /etc/shadow  cat, ls, grep  guess file names based on others  page11.php --> page12.php  loginfailure.jsp --> loginsuccess.jsp  accounts/myaccount.html --> accounts/youraccount.html  brute force / web spiders  port scanners
  • 17. 17 Other attacks  Attacking GET parameters  Attacking hidden input fields  Attacking cookies  Injecting malicious script code (XSS)  Injecting malicious SQL queries (SQL injection)
  • 19. 19 Methods of security  Security through obscurity: Relying on the fact that attackers don't know something needed to harm you.  Example: "If an attacker pointed their browser to http://foo.com/passwords.txt, they'd get our passwords. But nobody knows that file is there, so we are safe."  Example: "Our authentication database goes down for 2 minutes every night at 4am. During that time any user can log in without restrictions. But no one knows this, and the odds of a login at that time are miniscule."
  • 20. 20 Secure authentication  Force users to log in to your system before performing sensitive operations  Use secure protocols (https, etc.) to prevent sniffing  Force users to use strong passwords  not "password", "abc", same as user name, etc.
  • 21. 21 Principle of least privilege  principle of least privilege: Having just enough authority to get the job done (and no more!).  Examples:  A web server should only be given access to the set of HTML files that the web server is supposed to serve.  Code should not "run as root" or as a highly privileged user unless absolutely necessary.  Turn off unnecessary services on your web server  disable SSH, VNC, sendmail, etc.  close all ports except 80, others needed for web traffic
  • 22. 22 Sanitizing inputs  sanitizing inputs: Encoding and filtering untrusted user input before accepting it into a trusted system.  Ensure that accepted data is the right type, format, length...  Disallow entry of bad data into an HTML form.  Remove any SQL code from submitted user names.  HTML-encode any input text that is to be displayed back to the user as HTML or JavaScript.
  • 23. 23 Verifying that code is secure  Before code is written:  considering security in the design process  As code is being written:  code reviews  pair programming  After code has been written:  walkthroughs  security audits
  • 24. 24 Security audits  security audit: Series of checks and questions to assess the security of your system  can be done by an internal or external auditor  best if done as a process, not an individual event  penetration test: Targeted white-hat attempt to compromise your system's security  not unlike our attempts to break CSE 144's turnin page  risk analysis: Assessment of relative risks of what can go wrong when security is compromised
  • 25. 25 Security audit questions  Does your system require secure authentication with passwords?  Are passwords difficult to crack?  Are there access control lists (ACLs) in place on network devices?  Are there audit logs to record who accesses data?  Are the audit logs reviewed?  Are your OS security settings up to accepted industry levels?  Have all unnecessary applications and services been eliminated?  Are all operating systems and applications patched to current levels?  How is backup media stored? Who has access to it? Is it up-to-date?  Is there a disaster recovery plan? Has it ever been rehearsed?  Are there good cryptographic tools in place to govern data encryption?  Have custom-built applications been written with security in mind?  How have these custom applications been tested for security flaws?  How are configuration and code changes documented at every level? How are these records reviewed and who conducts the review?