OWASP - User contributions [en]

Reverse Tabnabbing

2018-06-18T11:55:46Z

Raul Siles: Added new reference (to demo)

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Reverse tabnabbing is an attack where a page linked from the target page is able to rewrite that page, for example to replace it with a phishing site. As the user was originally on the correct page they are less likely to notice that it has been changed to a phishing site, especially it the site looks the same as the target. If the user authenticates to this new page then their credentials (or other sensitive data) are sent to the phishing site rather than the legitimate one.

As well as the target site being able to overwrite the target page, any http link can be spoofed to overwrite the target page if the user is on an unsecured network, for example a public wifi hotspot. The attack is possible even if the target site is only available via https as the attacker only needs to spoof the http site that is being linked to.

The attack is typically possible when the source site uses a <code>target</code> instruction in a html link to specify a [https://www.w3schools.com/tags/att_a_target.asp target loading location] that do not replace the current location and then let the current window/tab available and does not include any of the preventative measures detailed below.

The attack is also possible for link opened via the <code>window.open</code> javascript function.

==Overview==

===With back link===

Link between parent and child pages when prevention attribute is not used:

[[File:TABNABBING_OVERVIEW_WITH_LINK.png]]

===Without back link===

Link between parent and child pages when prevention attribute is used:

[[File:TABNABBING_OVERVIEW_WITHOUT_LINK.png]]

==Examples==

Vulnerable page:

<syntaxhighlight lang="html">
<html>
<body>
<li><a href="bad.example.com" target="_blank">Vulnerable target using html link to open the new page</a></li>
<button onclick="window.open('https://bad.example.com')">Vulnerable target using javascript to open the new page</button>
</body>
</html>
</syntaxhighlight>

Malicious Site that is linked to:

<syntaxhighlight lang="html">
<html>
<body>
<script>
if (window.opener) {
window.opener.location = "https://phish.example.com";
}
</script>
</body>
</html>
</syntaxhighlight>

When a user clicks on the '''Vulnerable Target''' link/button then the '''Malicious Site''' is opened in a new tab (as expected) but the target site in the original tab is replaced by the phishing site.

==Accessible properties==

The malicious site can only access to the following properties from the '''opener''' javascript object reference (that is in fact a reference to a '''window''' javascript class instance) in case of '''cross origin''' (cross domains) access:
* ''opener.closed'': Returns a boolean value indicating whether a window has been closed or not.
* ''opener.frames'': Returns all iframe elements in the current window.
* ''opener.length'': Returns the number of iframe elements in the current window.
* ''opener.opener'': Returns a reference to the window that created the window.
* ''opener.parent'': Returns the parent window of the current window.
* ''opener.self'': Returns the current window.
* ''opener.top'': Returns the topmost browser window.

If the domains are the same then malicious site can access to all the properties exposed by the '''[https://www.w3schools.com/jsref/obj_window.asp window]''' javascript object reference.

==Prevention==

Prevention information are documented into the [[HTML5_Security_Cheat_Sheet#Tabnabbing| HTML5 Cheat Sheet]].

==References==

* https://dev.to/ben/the-targetblank-vulnerability-by-example - The <code>target="_blank"</code> vulnerability by example
* https://mathiasbynens.github.io/rel-noopener/ - About <code>rel=noopener</code> attribute values
* https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c - Target="_blank" — the most underestimated vulnerability ever
* Cure53's [https://github.com/cure53/browser-sec-whitepaper/raw/master/browser-security-whitepaper.pdf Browser Security White Paper] - Page 247
* https://danielstjules.github.io/blankshield/ - Reverse tabnabbing and blackshield demo

__NOTOC__

[[Category:Attack]]

OWASP Mobile Security Testing Guide

2017-05-03T13:28:03Z

Raul Siles: Fixed broken links to the list of Crackmes and to the first two iOS Crackme samples

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_MSTG_Header.jpg|link=]]</div>


{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==Our Vision ==

=== '''"Define the industry standard for mobile application security."''' ===

We are writing a security standard for mobile apps and a comprehensive testing guide that covers the processes, techniques, and tools used during a mobile app security test, as well as an exhaustive set of test cases that enables testers to deliver consistent and complete results.

== Main Deliverables ==

{| cellpadding="5"
|-
| [[File:mstg-mini-2.jpg|link=https://www.github.com/OWASP/owasp-mstg/]]
| '''Mobile Security Testing Guide'''
A comprehensive guide for iOS and Android mobile security testers with the following content:
# Mobile platform internals
# Testing in the secure development lifecycle
# Basic white-box and black-box security testing
# Mobile reverse engineering and tampering
# Assessing software protections
# Detailed white-box and black-box test cases that map to the requirements in the MASVS.
The MSTG is a work-in-progress. Currently, we hope to be "feature-complete" in Q3 2017. You can contribute and comment in the [https://github.com/OWASP/owasp-mstg GitHub Repo]. A book version of the current master branch is available on [https://b-mueller.gitbooks.io/owasp-mobile-security-testing-guide/content/ Gitbook].
|-
| [[File:masvs-sample-mini.jpg|link=https://www.owasp.org/images/f/fe/MASVS_v0.9.3.pdf]]
| '''Mobile App Security Requirements and Verification'''
The [https://www.owasp.org/images/f/fe/MASVS_v0.9.3.pdf OWASP Mobile Application Security Verification Standard (MASVS)] is a standard for mobile app security. It can be used by mobile software architects and developers seeking to develop secure mobile applications, as well as security testers to ensure completeness and consistency of test results. The latest release is [https://www.owasp.org/images/f/fe/MASVS_v0.9.3.pdf version 0.9.3].
|-
| [[File:checklist.jpg|link=https://www.owasp.org/images/1/1b/Mobile_App_Security_Checklist_0.9.3.xlsx]]
| '''Mobile App Security Checklist'''
A checklist for use in security assessments. Also contains links to the MSTG test case for each requirement. The current release is [https://www.owasp.org/images/1/1b/Mobile_App_Security_Checklist_0.9.3.xlsx version 0.9.3].
|}

[[Category:OWASP Project]]
[[Category:OWASP_Breakers]]
[[Category:OWASP_Document]]


| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="center" width="50%" | [[File:Owasp-breakers-small.png|link=https://www.owasp.org/index.php/Breakers]]
|
|-
| align="center" valign="center" width="50%" |
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

== Project Leaders ==

<span style="color:#ff0000">

[https://www.owasp.org/index.php/User:Bernhard_Mueller Bernhard Mueller]

[https://www.owasp.org/index.php/User:Sven_Schleier Sven Schleier]

== Road Map ==

* Q3 2017: Beta release
* Q4 2017: Version 1.0
* Q1 2018: Produce A Printable Book

== Parent Project ==

[[OWASP_Mobile_Security_Project]]

==Licensing==

The guide is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

|}

=How-To=

== Using the OWASP Mobile App Security Verification Standard, Testing Guide and Checklist ==

The documents produced in this project cover many aspects of mobile application security, from the high-level requirements to the nitty-gritty implementation details and test cases. They can be used to plan and verify security controls during any phase of mobile app development, as well as during pre-release code review and penetration testing.

# The [https://www.owasp.org/images/f/f2/OWASP_Mobile_AppSec_Verification_Standard_v0.9.2.pdf Mobile Application Security Verification Standard (MASVS)] contains generic security requirements along with mappings to verification levels that can be chosen depending on the overall need for security.
# The [https://github.com/OWASP/owasp-mstg Mobile Security Testing Guide (MSTG)] provides verification instructions for each requirement in the MASVS, as well as security best practices for apps on each supported mobile operating system (currently Android and iOS). It is also useful as a standalone learning resource and reference guide for mobile application security testers.
# The [https://www.owasp.org/images/6/6f/Mobile_App_Security_Checklist_0.9.2.xlsx Mobile App Security Checklist] can be used to apply the MASVS requirements during practical assessments. It also conveniently links to the MSTG test case for each requirement, making mobile penetration testing a breeze.

It is important to note that the security standard, testing guide and checklists are closely related: They all map to the same basic set of requirements. Depending on the context, the documents can be used stand-alone or in combination to achieve different objectives.

[[File:Overview-800px.jpg]]

For example, the MASVS requirements may be used in the planning and architecture design stages, while the checklist and testing guide may serve as a baseline for manual security testing or as a template for automated security tests.

== Mobile App Security Testing ==

The [https://www.owasp.org/images/9/94/Mobile_App_Security_Verification_Checklist_0.8.2.xlsx checklist] works great as a reference during mobile app security assessments. You can walk through the requirements one-by-one - for more information on each requirement, simply click on the link in the "Testing procedures" column. Or, fill out the checklist at the end of an assessment to ensure completeness.

== Security Engineering in the SDLC ==

Properly defined security requirements are an important part of the Secure SDLC. The [https://www.owasp.org/images/f/f2/OWASP_Mobile_AppSec_Verification_Standard_v0.9.2.pdf MASVS] levels can be used along with threat modeling to determine the appropriate set of security controls for a particular mobile app. MASVS V1 also lists requirements pertaining to the architecture and design of the mobile apps, as well as general processes and activities that should be part of the development process.

== Mobile App Security Education ==

The [https://github.com/OWASP/owasp-mstg Mobile Security Testing Guide] can be used as a standalone learning resource. Its main chapters contain general how-tos and tutorials that cover a variety of topics from mobile OS internals to advanced reverse engineering techniques.

=News=

== April 5th, 2017: Mobile App Security Verification Standard Update ==

[https://www.owasp.org/images/f/fe/MASVS_v0.9.3.pdf Version 0.9.3] of the MASVS is now [https://www.owasp.org/images/f/fe/MASVS_v0.9.3.pdf available for download] . This release contains several bug fixes and modifications to security requirements:

* Merged requirements 7.8 and 7.9 into for simplification
* Removed Anti-RE controls 8.1 and 8.2
* Updated MSTG links to current master
* Section "Environmental Interaction" renamed to "Platform Interaction"
* Removed To-dos
* Fixed some wording & spelling issues

== January 31st, 2017: Mobile App Security Verification Standard v0.9.2 Available For Download ==

The Mobile App Security Verification Standard (MASVS) has undergone a major revision, including a re-design of the security model and verification levels. We also revised many security requirements to address the multitude of [https://github.com/OWASP/owasp-masvs/issues?q=is%3Aissue%20 issues raised on GitHub]. The result is MASVS v0.9.2, which is now [https://www.owasp.org/images/f/f2/OWASP_Mobile_AppSec_Verification_Standard_v0.9.2.pdf available for download in PDF format].

As the MASVS is nearing maturity, we have decided to freeze the requirements until the Mobile Testing Guide and checklists "catch up" (due to the one-to-one mapping between requirements in the MASVS and MSTG, changes to the requirements make it necessary to update the other documents as well, causing repeated effort). Unless major issues pop up, the current list will therefore remain in place until MASVS/MSTG v1.0, and further changes will be reserved for v1.1 or later releases.

The MASVS is a community effort to establish security requirements for designing, developing and testing secure mobile apps on iOS and Android. Join the [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel] to meet the project members! You can sign up for an account [http://owasp.herokuapp.com/ here].

== January 28th, 2017: Mobile Crackmes and Reversing Tutorials ==
{| cellpadding="5"
|-
| [[File:uncrackable-250.png|link=]]
|
A key goal of the OWASP Mobile Testing Project is to build the ultimate learning resource and reference guide for mobile app reversers. As hands-on hacking is by far the best way to learn, we'd like to link most of the content to practical examples.

Starting now, we'll be adding [https://github.com/OWASP/owasp-mstg/tree/master/Crackmes crackmes for Android and iOS] to the [https://github.com/OWASP/owasp-mstg GitHub repo] that will then be used as examples throughout the guide. The goal is to collect enough resources for demonstrating the most important tools and techniques in our guide, plus additional crackmes for practicing. For starters there are three challenges:

* [https://github.com/OWASP/owasp-mstg/tree/master/OMTG-Files/02_Crackmes/01_Android/01_License_Validation Android License Validator]
* [https://github.com/OWASP/owasp-mstg/tree/master/Crackmes/iOS/Level_01/ Uncrackable App for iOS Level 1]
* [https://github.com/OWASP/owasp-mstg/tree/master/Crackmes/iOS/Level_02/ Uncrackable App for iOS Level 2]

|}

One of these three already has a [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05b-Reverse-Engineering-and-Tampering-Android.md#symbolicexec documented solution] in the guide. Tutorials for solving the other two [https://github.com/OWASP/owasp-mstg/blob/master/OMTG-Files/02_Crackmes/List_of_Crackmes.md still need to be added].

=== We Need More Authors and Contributors! ===

Maybe you have noticed that [https://rawgit.com/OWASP/owasp-mstg/master/Generated/OWASP-MSTG-Table-of-Contents.html the reverse engineering sections in the Mobile Testing Guide are incomplete]. The reason: We're still in the starting stages and don't have a lot of authors and contributors (in fact, 99% of the reversing content was produced by one guy). We'd love to welcome *you* as a contributor of crackmes, tutorials, writeups, or simply new ideas for this project.

==== What You Can Do ====

The OWASP MSTG is an open project and there's a lot of flexibility - it mostly depends on your skill set and willingness to commit your time. That said, the some areas that need help are:

* Solving crackmes and contributing a tutorial to the guide (preferable a technique that's not already documented. Check the [https://rawgit.com/OWASP/owasp-mstg/master/Generated/OWASP-MSTG-Table-of-Contents.html TOC] first).
* Writing and adding new crackmes along with solutions (should also describe something not already in the guide. Cracking white-boxes, dynamic analysis using an emulator / introspection, etc. etc.).
* General reversing write-ups to describe specific processes and techniques
* Help us figure out [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x07b-Assessing_Software_Protections.md resiliency testing processes] and [https://github.com/b-mueller/obfuscation-metrics obfuscation metrics]

The reversing part of the guide consists of the following chapters:

* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05-Testing-Processes-and-Techniques.md#tampering-and-reverse-engineering Tampering and Reverse Engineering - General Overview]
* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05b-Reverse-Engineering-and-Tampering-Android.md#tampering-and-reverse-engineering-on-android Tampering and Reverse Engineering on Android]
* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Reverse-Engineering-and-Tampering-iOS.md#tampering-and-reverse-engineering-on-ios Tampering and Reverse Engineering on iOS]

==== How To Join ====

Read the [https://github.com/OWASP/owasp-mstg/blob/master/authors_guide.md author's guide] first, and join the [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel], where you'll find all the other project members. You can sign up for an account [http://owasp.herokuapp.com/ here].

== January 22nd, 2017: Mobile Testing Guide TOC Available ==

As of now, we'll be auto-generating a [https://rawgit.com/OWASP/owasp-mstg/master/Generated/OWASP-MSTG-Table-of-Contents.html table of contents] out of the current MSTG master branch. This reflects the current state of the guide, and should make it easier to coordinate work between authors. A short-term goal is to finalize the structure of the guide so we get a clearer picture of what will be included in the final document. Lead authors are encouraged to complete the outline of their respective chapters.

'''On another note, we still need additional authors to help with all sections of the guide, including mobile operating system overviews, testing processes and techniques, and reverse engineering.''' Especially iOS authors are in short supply! As usual, ping us on the [https://owasp.slack.com/messages/project-mobile_omtg/details/ Slack Channel] if you want to contribute.

== December 4th, 2016: Call For Authors: The Ultimate Open-Source Mobile App Reverse Engineering Guide ==

Reverse engineering is an art, and describing every available facet of it would fill a whole library. The sheer range techniques and possible specializations is mind-blowing: One can spend years working on a very specific, isolated sub-problem, such as automating malware analysis or developing novel de-obfuscation methods. For mobile app security testers, it can be challenging to filter through the vast amount of information and build a working methodology. Things become even more problematic when one is tasked to assess apps that are heavily obfuscated and have anti-tampering measures built in.

One of the main goals in the MSTG is to build the ultimate resource for mobile reverse engineers. This includes not only basic static and dynamic analysis, but also advanced de-obfuscation, scripting and automation. Obviously, writing all this content is a lot of work, both in terms of general content and OS-specific how-tos. We're therefore looking for talented authors that want to join the project early on. Topics include the following:

* Basic Hybrid Static/Dynamic Analysis
* Code Injection and Dynamic Instrumentation (Substrate, FRIDA)
* Dynamic Binary Instrumentation (Valgrind, PIE)
* Analysis Frameworks (Metasm / Miasm)
* Symbolic Execution
* DCA and DPA attacks on white-box crypto
* Dynamic analysis frameworks (PANDA / DroidScope,...)
* Anything else we might have missed

=== What is in for me? ===

All of this is unpaid, volunteer work. However, depending on your contribution, you will be named in the "lead authors" or "contributors" list, and you'll be able to point to the fact that you co-authored the guide. You'll also be contributing to the field, helping others who are just starting out, and in turn becoming a happier person yourself (reaping the full benefits of your altruism).

=== Where do I sign up? ===

First of all, have a look at the existing RE chapters outline:

* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05-Testing-Processes-and-Techniques.md#tampering-and-reverse-engineering Generic / Introduction]
* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05b-Reverse-Engineering-and-Tampering-Android.md Android]
* [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Reverse-Engineering-and-Tampering-iOS.md#tampering-and-reverse-engineering-on-ios iOS]

You'll probably immediately have ideas on how you can contribute. If that's the case, read the [https://github.com/OWASP/owasp-mstg/blob/master/authors_guide.md author's guide] first.

Then contact [https://github.com/b-mueller Bernhard Mueller] - ideally directly on the [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel], where you'll find all the other project members. You can sign up for an account [http://owasp.herokuapp.com/ here].

=FAQs=

==How can I participate in your project?==

'''We are searching for additional authors, reviewers and editors.''' The best way to get started is to browse the [https://b-mueller.gitbooks.io/owasp-mobile-security-testing-guide/content/ existing content]. Also, check the [https://github.com/OWASP/owasp-mstg/projects/1 project dashboard] for a list of open tasks.

Drop a us line on the [https://owasp.slack.com/messages/project-mobile_omtg/details/) Slack channel] before you start working on a topic. This helps us to keep track of what everyone is doing and prevent conflicts. You can create a Slack account here:

http://owasp.herokuapp.com/

Before you start contributing, please read our brief [https://github.com/OWASP/owasp-mstg/blob/master/style_guide.md style guide] which contains a few basic writing rules.

If there's something you really want to see in the guide, or you want to suggest an improvement, create an issue [https://github.com/OWASP/owasp-mstg/issues issue] or ping us on [https://owasp.slack.com/messages/project-mobile_omtg/details/ Slack].

==Where do you guys need help the most?==

There's a lot of areas where you can help out:

* Writing original content, such as describing testing processes and writing test cases. We're all doing this in our spare time, which unfortunately means that things sometimes slow down to a crawl. If you're knowledgeable in some area and have time available, we'd be incredibly thankful to anyone who contributes, even if it's only one or two test cases.

* Reviewing content and giving feedback. The proper channel for questions and feedback is the GitHub issues system of the respective repo, contacting us on [https://owasp.slack.com/messages/project-mobile_omtg/details/ OWASP Mobile Security Project Slack Channel] is another possibility.

* Developing tools. For example, we still don't have an automated way of generating checklists out of the GitHub repo.

* Contributing to auxiliary projects: The [https://github.com/b-mueller/obfuscation-metrics obfuscation metrics project] is an auxiliary project that deals with specific forms of control flow and data obfuscation. This project needs experts in advanced obfuscation / de-obfuscation. Please contact us if you have experience in this area.

==If I am not a programmer can I participate in your project?==
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

==I contributed to the original Google Doc, but I'm not credited in the new version of the MSTG? ==
As we migrated some of the existing content, we did our best to backtrack the original authors and credit them appropriately. We also added a [https://github.com/OWASP/owasp-mstg/blob/master/Document/0x02-Frontispiece.md revision history] that lists all the authors from old Google Docs. If you are not on that list but feel you should be, please contact [https://github.com/b-mueller Bernhard] or [https://github.com/sushi2k Sven] and they'll fix it. Or better yet, re-join the author's team and start contributing to the new guide.

= Acknowledgements =

==Contributors==

The Mobile Security Testing Guide was initiated by [https://www.owasp.org/index.php/User:Milan_Singh_Thakur Milan Singh Thakur] in 2015. The original document was hosted on Google Drive. Guide development was moved to GitHub in October 2016. Below is the full list of contributors for each revision.

=== MSTG in its current form ===

'''Authors:'''

* Bernhard Mueller
* Sven Schleier

'''Contributors:'''

* Abdessamad Temmar
* Francesco Stillavato
* Pawel Rzepa
* Gerhard Wagner
* Daniel Ramirez Martin
*Jin Kung Ong
* Alexander Antukh
* Claudia André
* Ryan Teoh
* Prathan Phongthiproek
* Jeroen Willemsen
* Romuald Szkudlarek
* Luander Ribeiro
* Pishu Mahtani
* Sebastian Banescu
* Prabhant Singh
* Stephen Corbiaux
* Ali Yazdani

'''Reviewers:'''

=== MSTG "Beta 2" on Google Drive ===

'''Authors:'''

* Mirza Ali
* Stephen Corbiaux
* Ryan Dewhurst
* Mohammad Hamed Dadpour
* David Fern
* Ali Yazdani
* Bao Lee
* Anto Joseph
* Nutan Kumar Panda
* Rahil Parikh
* Julian Schütte
* Abhinav Sejpal
* Anant Shrivastava
* Pragati Singh
* Milan Singh Thakur
* Stephanie Vanroelen
* Gerhard Wagner

'''Reviewers:'''

* Andrew Muller
* Jonathan Carter
* Stephanie Vanroelen
* Milan Singh Thakur

=== MSTG "Beta 1" on Google Drive ===

'''Authors:'''

*Mirza Ali
*Mohammad Hamed Dadpour
*David Fern
*Rahil Parikh
*Abhinav Sejpal
*Pragati Singh
*Milan Singh Thakur

'''Reviewers:'''

*Andrew Muller
*Jonathan Carter

'''Top Contributors:'''

*Jim Manico
*Yair Amit
*Amin Lalji
*OWASP Mobile Team


__NOTOC__ <headertabs></headertabs>

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP_Document]]

OWASP Testing Guide v4 Table of Contents

2016-11-09T14:16:43Z

Raul Siles: Fixed current link to the OTG v4 guide

{{OWASP Breakers}}
__NOTOC__

'''This is the FINAL table of content of the New Testing Guide v4.'''<br>

<br>You can download the Guide [https://www.owasp.org/images/1/19/OTGv4.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Testing Guide Wiki last Updated: April 2016'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==

==[[Testing Guide Frontispiece |1. Frontispiece]]==

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

==[[Testing Guide Introduction|2. Introduction]]==

'''[[Testing Guide Introduction#The_OWASP_Testing Project|2.1 The OWASP Testing Project]]'''

'''[[Testing Guide Introduction#Principles_of_Testing|2.2 Principles of Testing]]'''

'''[[Testing Guide Introduction#Testing_Techniques_Explained|2.3 Testing Techniques Explained]]'''

'''[[Testing Guide Introduction#Manual_Inspections_.26_Reviews|2.4 Manual Inspections & Reviews]]'''

'''[[Testing Guide Introduction#Threat_Modeling|2.5 Threat Modeling]]'''

'''[[Testing Guide Introduction#Source_Code_Review|2.6 Source Code Review]]'''

'''[[Testing Guide Introduction#Penetration_Testing|2.7 Penetration Testing]]'''

'''[[Testing Guide Introduction#The_Need_for_a_Balanced_Approach|2.8 The Need for a Balanced Approach]]'''

'''[[Testing Guide Introduction#Deriving_Security_Test_Requirements|2.9 Deriving Security Test Requirements]]'''

'''[[Testing Guide Introduction#Security_Tests_Integrated_in_Development_and_Testing_Workflows|2.10 Security Tests Integrated in Development and Testing Workflows]]'''

'''[[Testing Guide Introduction#Security_Test_Data_Analysis_and_Reporting|2.11 Security Test Data Analysis and Reporting]]'''

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''[[The_OWASP_Testing_Framework#Overview|3.1 Overview]]'''

'''[[The_OWASP_Testing_Framework#Phase_1:_Before_Development_Begins|3.2 Phase 1: Before Development Begins]]'''

'''[[The_OWASP_Testing_Framework#Phase_2:_During_Definition_and_Design|3.3 Phase 2: During Definition and Design]]'''

'''[[The_OWASP_Testing_Framework#Phase_3:_During_Development|3.4 Phase 3: During Development]]'''

'''[[The_OWASP_Testing_Framework#Phase_4:_During_Deployment|3.5 Phase 4: During Deployment]]'''

'''[[The_OWASP_Testing_Framework#Phase_5:_Maintenance_and_Operations|3.6 Phase 5: Maintenance and Operations]]'''

'''[[The_OWASP_Testing_Framework#A_Typical_SDLC_Testing_Workflow|3.7 A Typical SDLC Testing Workflow]]'''

'''[[Penetration testing methodologies |3.8 Penetration Testing Methodologies]]'''

==[[Web Application Penetration Testing |4. Web Application Security Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']]

[[Testing Checklist| 4.1.1 Testing Checklist]]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Conduct_search_engine_discovery/reconnaissance_for_information_leakage_(OTG-INFO-001) |4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]]

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]]

[[Review_Webserver_Metafiles_for_Information_Leakage_(OTG-INFO-003) |4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]]

[[Enumerate Applications on Webserver (OTG-INFO-004) |4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]]

[[Review_webpage_comments_and_metadata_for_information_leakage_(OTG-INFO-005) |4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]]

[[Identify_application_entry_points_(OTG-INFO-006) |4.2.6 Identify application entry points (OTG-INFO-006) ]]

[[Map_execution_paths_through_application_(OTG-INFO-007) |4.2.7 Map execution paths through application (OTG-INFO-007)]]

[[Fingerprint_Web_Application_Framework_(OTG-INFO-008) |4.2.8 Fingerprint Web Application Framework (OTG-INFO-008) ]]

[[Fingerprint_Web_Application_(OTG-INFO-009) |4.2.9 Fingerprint Web Application (OTG-INFO-009) ]]

[[Map_Application_Architecture_(OTG-INFO-010) |4.2.10 Map Application Architecture (OTG-INFO-010) ]]

[[Testing for configuration management|'''4.3 Configuration and Deployment Management Testing ''']]

[[Test Network/Infrastructure Configuration (OTG-CONFIG-001)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]]

[[Test Application Platform Configuration (OTG-CONFIG-002)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]]

[[Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]]

[[Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]]

[[Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]]

[[Test HTTP Methods (OTG-CONFIG-006)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]]

[[Test HTTP Strict Transport Security (OTG-CONFIG-007)|4.3.7 Test HTTP Strict Transport Security (OTG-CONFIG-007) ]]

[[Test RIA cross domain policy (OTG-CONFIG-008)|4.3.8 Test RIA cross domain policy (OTG-CONFIG-008) ]]

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]]

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]]

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]]

[[Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]]

[[Testing for Weak or unenforced username policy (OTG-IDENT-005)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]]

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]]

[[Testing for default credentials (OTG-AUTHN-002)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]]

[[Testing for Weak lock out mechanism (OTG-AUTHN-003)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]]

[[Testing for Bypassing Authentication Schema (OTG-AUTHN-004)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]]

[[Testing for Vulnerable Remember Password (OTG-AUTHN-005)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]]

[[Testing for Browser cache weakness (OTG-AUTHN-006)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]]

[[Testing for Weak password policy (OTG-AUTHN-007)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]]

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]]

[[Testing for weak password change or reset functionalities (OTG-AUTHN-009)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]]

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]]

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Testing_Directory_traversal/file_include_(OTG-AUTHZ-001) |4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-001)]]

[[Testing for Bypassing Authorization Schema (OTG-AUTHZ-002)|4.6.2 Testing for bypassing authorization schema (OTG-AUTHZ-002)]]

[[Testing for Privilege escalation (OTG-AUTHZ-003)|4.6.3 Testing for Privilege Escalation (OTG-AUTHZ-003)]]

[[Testing for Insecure Direct Object References (OTG-AUTHZ-004)|4.6.4 Testing for Insecure Direct Object References (OTG-AUTHZ-004)]]

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OTG-SESS-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]]

[[Testing for cookies attributes (OTG-SESS-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]]

[[Testing for Session Fixation (OTG-SESS-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]]

[[Testing for Exposed Session Variables (OTG-SESS-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]]

[[Testing for CSRF (OTG-SESS-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]]

[[Testing for logout functionality (OTG-SESS-006)|4.7.6 Testing for logout functionality (OTG-SESS-006)]]

[[Test Session Timeout (OTG-SESS-007)|4.7.7 Test Session Timeout (OTG-SESS-007)]]

[[Testing for Session puzzling (OTG-SESS-008)|4.7.8 Testing for Session puzzling (OTG-SESS-008)]]

[[Testing for Input Validation|'''4.8 Input Validation Testing''']]

[[Testing for Reflected Cross site scripting (OTG-INPVAL-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]]

[[Testing for Stored Cross site scripting (OTG-INPVAL-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]]

[[Testing for HTTP Verb Tampering (OTG-INPVAL-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]]

[[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]]

[[Testing for SQL Injection (OTG-INPVAL-005)| 4.8.5 Testing for SQL Injection (OTG-INPVAL-005)]]

[[Testing for Oracle|4.8.5.1 Oracle Testing]]

[[Testing for MySQL|4.8.5.2 MySQL Testing]]

[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.5.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.5.6 Testing for NoSQL injection]]

[[Testing for LDAP Injection (OTG-INPVAL-006)|4.8.6 Testing for LDAP Injection (OTG-INPVAL-006)]]

[[Testing for ORM Injection (OTG-INPVAL-007)|4.8.7 Testing for ORM Injection (OTG-INPVAL-007)]]

[[Testing for XML Injection (OTG-INPVAL-008)|4.8.8 Testing for XML Injection (OTG-INPVAL-008)]]

[[Testing for SSI Injection (OTG-INPVAL-009)|4.8.9 Testing for SSI Injection (OTG-INPVAL-009)]]

[[Testing for XPath Injection (OTG-INPVAL-010)|4.8.10 Testing for XPath Injection (OTG-INPVAL-010)]]

[[Testing for IMAP/SMTP Injection (OTG-INPVAL-011)|4.8.11 IMAP/SMTP Injection (OTG-INPVAL-011)]]

[[Testing for Code Injection (OTG-INPVAL-012)|4.8.12 Testing for Code Injection (OTG-INPVAL-012)]]

[[Testing for Local File Inclusion|4.8.12.1 Testing for Local File Inclusion]]

[[Testing for Remote File Inclusion|4.8.12.2 Testing for Remote File Inclusion]]

[[Testing for Command Injection (OTG-INPVAL-013)|4.8.13 Testing for Command Injection (OTG-INPVAL-013)]]

[[Testing for Buffer Overflow (OTG-INPVAL-014)|4.8.14 Testing for Buffer overflow (OTG-INPVAL-014)]]

[[Testing for Heap Overflow|4.8.14.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.14.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.14.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OTG-INPVAL-015)|4.8.15 Testing for incubated vulnerabilities (OTG-INPVAL-015)]]

[[Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)|4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016) ]]

[[Testing for HTTP Incoming requests (OTG-INPVAL-017)|4.8.17 Testing for HTTP Incoming Requests (OTG-INPVAL-017) ]]

[[Testing for Error Handling|'''4.9 Testing for Error Handling''']]

[[Testing for Error Code (OTG-ERR-001)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]]

[[Testing for Stack Traces (OTG-ERR-002)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]]

[[Testing for weak Cryptography|'''4.10 Testing for weak Cryptography''']]

[[Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)| 4.10.1 Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)]]

[[Testing for Padding Oracle (OTG-CRYPST-002)| 4.10.2 Testing for Padding Oracle (OTG-CRYPST-002)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)|4.10.3 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)]]

[[Testing for business logic|'''4.11 Business Logic Testing''']]

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.11.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.11.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.11.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-004)|4.11.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-005)|4.11.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)|4.11.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-007)|4.11.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)|4.11.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-009)|4.11.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

[[Client Side Testing|'''4.12 Client Side Testing''']]<br>

[[Testing for DOM-based Cross site scripting (OTG-CLIENT-001)|4.12.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]]

[[Testing for JavaScript Execution (OTG-CLIENT-002)|4.12.2 Testing for JavaScript Execution (OTG-CLIENT-002)]]

[[Testing for HTML Injection (OTG-CLIENT-003)|4.12.3 Testing for HTML Injection (OTG-CLIENT-003)]]

[[Testing for Client Side URL Redirect (OTG-CLIENT-004)|4.12.4 Testing for Client Side URL Redirect (OTG-CLIENT-004)]]

[[Testing_for_CSS_Injection (OTG-CLIENT-005)|4.12.5 Testing for CSS Injection (OTG-CLIENT-005)]]

[[Testing_for_Client_Side_Resource_Manipulation (OTG-CLIENT-006)|4.12.6 Testing for Client Side Resource Manipulation (OTG-CLIENT-006)]]

[[Test Cross Origin Resource Sharing (OTG-CLIENT-007)|4.12.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]]

[[Testing for Cross site flashing (OTG-CLIENT-008)|4.12.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]]

[[Testing for Clickjacking (OTG-CLIENT-009)|4.12.9 Testing for Clickjacking (OTG-CLIENT-009)]]

[[Testing WebSockets (OTG-CLIENT-010)|4.12.10 Testing WebSockets (OTG-CLIENT-010)]]

[[Test Web Messaging (OTG-CLIENT-011)|4.12.11 Test Web Messaging (OTG-CLIENT-011)]]

[[Test Local Storage (OTG-CLIENT-012)|4.12.12 Test Local Storage (OTG-CLIENT-012)]]

[[Mobile Web service Testing|'''4.13 Mobile Web service Testing''']]<br>

[[Cloud Service Testing|'''4.14 Cloud Service Testing''']]<br>

[[Denial of Service Testing|'''4.15 Testing For HTTP DOS Attack''']]<br>

==[[Reporting |5. Reporting]]==

==[[Appendix A: Testing Tools |Appendix A: Testing Tools Resource]]==

Security Testing Tools
* http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines
* http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
* http://sectools.org/
* https://www.kali.org/
* http://www.blackarch.org/tools.html

Security Testing Tools in Virtual Image
* https://tools.pentestbox.com/
* https://sourceforge.net/p/samurai/wiki/Home/
* https://sourceforge.net/projects/santoku/
* https://sourceforge.net/projects/parrotsecurity/?source=navbar
* https://sourceforge.net/projects/matriux/?source=navbar
* http://www.blackarch.org/downloads.html
* https://www.kali.org/
* http://cyborg.ztrela.com/tools/
* http://www.caine-live.net/index.html
* http://www.pentoo.ch/download/
* http://bugtraq-team.com/

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==

* Whitepapers
* Books
* Useful Websites

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

* Input Encoding
* Output Encoding

----

[[Category:OWASP Testing Project]][[Category:Popular]]

OWASP Vulnerable Web Applications Directory Project/Pages/VMs

2016-10-20T17:21:14Z

Raul Siles: Updates Oct 20, 2016

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [https://github.com/rapid7/metasploitable3/wiki/Vulnerabilities Metasploitable 3 ]
| VMware
| [https://github.com/rapid7/metasploitable3 download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|-
| [http://www.ethicalhack3r.co.uk/wordpress-cd/ WordPress CD]
| VirtualBox
| [http://www.ethicalhack3r.co.uk/wpcd/WPCD.ova download]
| ethicalhack3r
| [http://www.randomstorm.com/wpscan-security-tool.php WPScan]
|-
| [http://xxe.sourceforge.net/ XXE ]
| VMware
| [http://sourceforge.net/projects/xxe/files/ download]
|
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2016-10-20T17:20:31Z

Raul Siles: Updates Oct 20, 2016

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [https://github.com/quantumfoam/DVNA/ Damn Vulnerable Node Application - DVNA ]
| Node.js
| [https://github.com/quantumfoam/DVNA/ download]
| Claudio Lacayo
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [https://www.owasp.org/index.php/OWASP_Juice_Shop_Project Juice Shop]
| Node/JS
| [https://github.com/bkimminich/juice-shop download]
| OWASP
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://github.com/jerryhoff/WebGoat.NET .NET Goat ]
| C#
| [https://github.com/jerryhoff/WebGoat.NET git repository]
| OWASP
|
|-
| [https://www.owasp.org/index.php/OWASP_Node_js_Goat_Project NodeGoat ]
| Node.js
| [https://github.com/OWASP/NodeGoat git repository]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://github.com/sectooladdict/wavsep WAVSEP - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://sourceforge.net/projects/wavsep/ download (builds)] [https://code.google.com/p/wavsep/downloads/list download (old)] [https://github.com/sectooladdict/wavsep/wiki wiki]
| Shay Chen
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://www.owasp.org/index.php/WebGoatPHP WebGoatPHP ]
| PHP
| [https://github.com/OWASP/OWASPWebGoatPHP download] [https://github.com/OWASP/OWASPWebGoatPHP/blob/master/README.md guide]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
| [https://github.com/s4n7h0/xvwa Xtreme Vulnerable Web Application (XVWA)]
| PHP/MySQL
| [https://github.com/s4n7h0/xvwa download]
| @s4n7h0, @samanL33T
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Online

2016-10-20T17:19:39Z

Raul Siles: Updates Oct 20, 2016

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://www.bgabank.com/ BGA Vulnerable BANK App]
| .NET
| BGA Security
|
|-
| [http://crackme.trustwave.com/ Crack Me Bank]
|
| Trustwave
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [https://public-firing-range.appspot.com/ Firing Range]
|
| Google
| [https://github.com/google/firing-range Source code]
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [http://hackazon.webscantest.com/ Hackazon]
| AJAX, JSON, XML, GwT, AMF
| NTObjectives
| [http://www.ntobjectives.com/hackazon/ Project page]
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://aspnet.testsparker.com/ Netsparker Test App .NET]
| ASP.NET
| Netsparker
|
|-
| [http://php.testsparker.com/ Netsparker Test App PHP]
| PHP
| Netsparker
|
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://testhtml5.vulnweb.com/ Security Tweets]
|
| Acunetix
| HTML5
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2016-01-22T21:18:45Z

Raul Siles: v20160122 - Added DVNA & NodeGoat

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [https://github.com/quantumfoam/DVNA/ Damn Vulnerable Node Application - DVNA ]
| Node.js
| [https://github.com/quantumfoam/DVNA/ download]
| Claudio Lacayo
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://bkimminich.github.io/juice-shop/; Juice Shop]
| Node
| [https://github.com/bkimminich/juice-shop download]
| [https://github.com/bkimminich; Bjorn Kimminich]
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://github.com/jerryhoff/WebGoat.NET .NET Goat ]
| C#
| [https://github.com/jerryhoff/WebGoat.NET git repository]
| OWASP
|
|-
| [https://www.owasp.org/index.php/OWASP_Node_js_Goat_Project NodeGoat ]
| Node.js
| [https://github.com/OWASP/NodeGoat git repository]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://github.com/sectooladdict/wavsep WAVSEP - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://sourceforge.net/projects/wavsep/ download (builds)] [https://code.google.com/p/wavsep/downloads/list download (old)] [https://github.com/sectooladdict/wavsep/wiki wiki]
| Shay Chen
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
| [https://github.com/s4n7h0/xvwa Xtreme Vulnerable Web Application (XVWA)]
| PHP/MySQL
| [https://github.com/s4n7h0/xvwa download]
| @s4n7h0, @samanL33T
|
|-
|}

OWASP Vulnerable Web Applications Directory Project

2016-01-22T21:14:43Z

Raul Siles:

OWASP Vulnerable Web Applications Directory Project

2016-01-22T21:14:06Z

Raul Siles:

OWASP Vulnerable Web Applications Directory Project/Pages/VMs

2016-01-22T21:11:13Z

Raul Siles:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|-
| [http://www.ethicalhack3r.co.uk/wordpress-cd/ WordPress CD]
| VirtualBox
| [http://www.ethicalhack3r.co.uk/wpcd/WPCD.ova download]
| ethicalhack3r
| [http://www.randomstorm.com/wpscan-security-tool.php WPScan]
|-
| [http://xxe.sourceforge.net/ XXE ]
| VMware
| [http://sourceforge.net/projects/xxe/files/ download]
|
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/VMsOld

2016-01-22T21:06:46Z

Raul Siles:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/VMs

2016-01-22T21:03:34Z

Raul Siles: Fixed layout

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|-
| [http://www.ethicalhack3r.co.uk/wordpress-cd/ WordPress CD]
| VirtualBox
| [http://www.ethicalhack3r.co.uk/wpcd/WPCD.ova download]
| ethicalhack3r
| [http://www.randomstorm.com/wpscan-security-tool.php WPScan]
|
|-
| [http://xxe.sourceforge.net/ XXE ]
| VMware
| [http://sourceforge.net/projects/xxe/files/ download]
|
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Online

2016-01-22T20:58:39Z

Raul Siles: Fixed layout

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.trustwave.com/ Crack Me Bank]
|
| Trustwave
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [https://public-firing-range.appspot.com/ Firing Range]
|
| Google
| [https://github.com/google/firing-range Source code]
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [http://hackazon.webscantest.com/ Hackazon]
| AJAX, JSON, XML, GwT, AMF
| NTObjectives
| [http://www.ntobjectives.com/hackazon/ Project page]
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://testhtml5.vulnweb.com/ Security Tweets]
|
| Acunetix
| HTML5
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Online

2016-01-22T20:56:59Z

Raul Siles: Fixed layout

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.trustwave.com/ Crack Me Bank]
|
| Trustwave
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [https://public-firing-range.appspot.com/ Firing Range]
|
| Google
| [https://github.com/google/firing-range Source code]
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [http://hackazon.webscantest.com/ Hackazon]
| AJAX, JSON, XML, GwT, AMF
| NTObjectives
| [http://www.ntobjectives.com/hackazon/ Project page]
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://testhtml5.vulnweb.com/ Security Tweets]
|
| Acunetix
| HTML5
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
}

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2016-01-21T22:18:56Z

Raul Siles: Added Juice Shop

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://bkimminich.github.io/juice-shop/; Juice Shop]
| Node
| [https://github.com/bkimminich/juice-shop download]
| [https://github.com/bkimminich; Bjorn Kimminich]
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://github.com/jerryhoff/WebGoat.NET .NET Goat ]
| C#
| [https://github.com/jerryhoff/WebGoat.NET git repository]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://github.com/sectooladdict/wavsep WAVSEP - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://sourceforge.net/projects/wavsep/ download (builds)] [https://code.google.com/p/wavsep/downloads/list download (old)] [https://github.com/sectooladdict/wavsep/wiki wiki]
| Shay Chen
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
| [https://github.com/s4n7h0/xvwa Xtreme Vulnerable Web Application (XVWA)]
| PHP/MySQL
| [https://github.com/s4n7h0/xvwa download]
| @s4n7h0, @samanL33T
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2016-01-21T22:10:27Z

Raul Siles: Added XVWA

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://github.com/jerryhoff/WebGoat.NET .NET Goat ]
| C#
| [https://github.com/jerryhoff/WebGoat.NET git repository]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://github.com/sectooladdict/wavsep WAVSEP - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://sourceforge.net/projects/wavsep/ download (builds)] [https://code.google.com/p/wavsep/downloads/list download (old)] [https://github.com/sectooladdict/wavsep/wiki wiki]
| Shay Chen
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
| [https://github.com/s4n7h0/xvwa Xtreme Vulnerable Web Application (XVWA)]
| PHP/MySQL
| [https://github.com/s4n7h0/xvwa download]
| @s4n7h0, @samanL33T
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Online

2016-01-21T22:03:06Z

Raul Siles: Fixed link to Crack Me Bank

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.trustwave.com/ Crack Me Bank]
|
| Trustwave
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [https://public-firing-range.appspot.com/ Firing Range]
|
| Google
| [https://github.com/google/firing-range Source code]
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [http://hackazon.webscantest.com/ Hackazon]
| AJAX, JSON, XML, GwT, AMF
| NTObjectives
| [http://www.ntobjectives.com/hackazon/ Project page]
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://testhtml5.vulnweb.com/ Security Tweets]
|
| Acunetix
| HTML5
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-

OWASP Vulnerable Web Applications Directory Project/Pages/VMs

2016-01-21T22:01:05Z

Raul Siles: Fixed layout

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|-
| [http://www.ethicalhack3r.co.uk/wordpress-cd/ WordPress CD]
| VirtualBox
| [http://www.ethicalhack3r.co.uk/wpcd/WPCD.ova download]
| ethicalhack3r
| [http://www.randomstorm.com/wpscan-security-tool.php WPScan]
|
|-
| [http://xxe.sourceforge.net/ XXE ]
| VMware
| [http://sourceforge.net/projects/xxe/files/ download]
|
|
|-

OWASP Vulnerable Web Applications Directory Project/Pages/VMs

2016-01-21T21:59:53Z

Raul Siles: Added empty line

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2015-11-09T21:29:23Z

Raul Siles: WAVSEP link updates

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://github.com/jerryhoff/WebGoat.NET .NET Goat ]
| C#
| [https://github.com/jerryhoff/WebGoat.NET git repository]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://github.com/sectooladdict/wavsep WAVSEP - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://sourceforge.net/projects/wavsep/ download (builds)] [https://code.google.com/p/wavsep/downloads/list download (old)] [https://github.com/sectooladdict/wavsep/wiki wiki]
| Shay Chen
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2015-11-09T20:19:53Z

Raul Siles: Duplicate WebGoat.NET project with new URL (from Codeplex to Github)

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://github.com/jerryhoff/WebGoat.NET .NET Goat ]
| C#
| [https://github.com/jerryhoff/WebGoat.NET git repository]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

OWASP Vulnerable Web Applications Directory Project/Pages/Offline

2015-10-04T07:51:29Z

Raul Siles: Added the "SQL injection test environment" (from the SQLmap Project) entry

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://www.owasp.org/index.php/OWASP_Security_Shepherd Security Shepherd]
| Java
| [https://sourceforge.net/projects/owaspshepherd/ download]
| OWASP
|
|-
| [https://github.com/sqlmapproject/testenv SQL injection test environment]
| PHP
|
|
| SQLmap Project
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Session Management Cheat Sheet

2015-04-16T13:56:41Z

Raul Siles: /* Used vs. Accepted Session ID Exchange Mechanisms */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.

'''''NOTE''''': Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too. It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies. In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

=== Renewal Timeout ===

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918

= Authors and Primary Editors =

Raul Siles (DinoSec) - raul[at]dinosec.com
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Session Management Cheat Sheet

2015-04-16T13:55:46Z

Raul Siles: /* Used vs. Accepted Session ID Exchange Mechanisms */ Note added.

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.

'''''NOTE''''': Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too. It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies. In the past, some web application used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting) if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

=== Renewal Timeout ===

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918

= Authors and Primary Editors =

Raul Siles (DinoSec) - raul[at]dinosec.com
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Session Management Cheat Sheet

2015-03-17T23:00:41Z

Raul Siles: /* Session ID Length */ Additional NOTE clarifying the reference ID length value of 128 bits.

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

'''''NOTE''''': The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section "Session ID Entropy". However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength. For example, there are well-known implementations, such as Microsoft ASP.NET, making use of 120-bit random numbers for its session IDs (represented by 20-character strings [10]) that can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or when cookies are not accepted due to user privacy concerns).

For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

=== Renewal Timeout ===

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918

= Authors and Primary Editors =

Raul Siles (DinoSec) - raul[at]dinosec.com
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Session Management Cheat Sheet

2015-03-17T22:57:02Z

Raul Siles: /* Related Articles */ New reference [10]

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or when cookies are not accepted due to user privacy concerns).

For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

=== Renewal Timeout ===

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

[10] '''How and why session IDs are reused in ASP.NET''' https://support.microsoft.com/en-us/kb/899918

= Authors and Primary Editors =

Raul Siles (DinoSec) - raul[at]dinosec.com
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Session Management Cheat Sheet

2014-04-29T11:39:07Z

Raul Siles:

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or when cookies are not accepted due to user privacy concerns).

For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

=== Renewal Timeout ===

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

= Authors and Primary Editors =

Raul Siles (DinoSec) - raul[at]dinosec.com
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Session Management Cheat Sheet

2014-04-29T11:32:55Z

Raul Siles: Minor review & fixes, updated author contact info, and added a new renewal timeout section.

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or when cookies are not accepted due to user privacy concerns).

For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on the criticality of the web application and its data. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

=== Renewal Timeout ===

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscientious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to reauthenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

= Authors and Primary Editors =

Raul Siles (DinoSec) - raul[at]dinosec.com
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

OWASP Vulnerable Web Applications Directory Project/Pages/VMs

2014-01-27T07:49:42Z

Raul Siles: Added WordPress CD

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|-
| [http://www.ethicalhack3r.co.uk/wordpress-cd/ WordPress CD]
| VirtualBox
| [http://www.ethicalhack3r.co.uk/wpcd/WPCD.ova download]
| ethicalhack3r
| [http://www.randomstorm.com/wpscan-security-tool.php WPScan]
|
|-
|}

OWASP Vulnerable Web Applications Directory Project

2014-01-27T07:42:27Z

Raul Siles: Added blog post and GitHub references

User:Raul Siles

2013-12-22T23:34:49Z

Raul Siles:

Raul Siles is founder and senior security analyst at DinoSec. For over a decade, he has applied his expertise performing advanced technical security services and innovating offensive and defensive solutions for large enterprises and organizations in various industries worldwide. He has been involved in security architecture design and reviews, penetration tests, incident handling, intrusion and forensic analysis, security assessments and vulnerability disclosure, web applications, mobile and wireless environments, and security research in new technologies. Throughout his career, starting with a strong technical background in networks, systems and applications in mission critical environments, he has worked as an information security expert, engineer, researcher and penetration tester at Hewlett Packard, as an independent consultant, and on his own companies, Taddong and DinoSec.

Raul is a certified instructor for the SANS Institute, regularly teaching penetration testing courses. He is an active speaker at international security conferences and events, such as RootedCON, Black Hat, OWASP, BruCON, etc. Mr. Siles is author of security training courses, blogs, books, articles, and tools, and actively contributes to community and open-source projects. He loves security challenges, and has been a member of international organizations, such as the Honeynet Project or the SANS Internet Storm Center. Raul is one of the few individuals worldwide who have earned the GIAC Security Expert (GSE) designation, as well as many other certifications. Raul holds a master's degree in computer science from UPM (Spain) and a postgraduate in security and e-commerce.

More information at http://www.raulsiles.com (@raulsiles) and http://www.dinosec.com (@dinosec).

OWASP Vulnerable Web Applications Directory Project

2013-11-20T21:10:17Z

Raul Siles: Added other compilations to ACK section

User:Raul Siles

2013-11-20T21:02:49Z

Raul Siles: New Bio for DinoSec

Raul Siles is founder and senior security analyst at DinoSec. For over a decade, he has applied his expertise performing advanced technical security services and innovating offensive and defensive solutions for large enterprises and organisations in various industries worldwide. He has been involved in security architecture design and reviews, penetration tests, incident handling, intrusion and forensic analysis, security assessments and vulnerability disclosure, web applications, mobile and wireless environments, and security research in new technologies. Throughout his career, starting with a strong technical background in networks, systems and applications in mission critical environments, he has worked as an information security expert, engineer, researcher and penetration tester at Hewlett Packard, as an independent consultant, and on his own companies, Taddong and DinoSec.

Raul is a certified instructor for the SANS Institute, regularly teaching penetration testing courses. He is an active speaker at international security conferences and events, such as RootedCON, Black Hat, OWASP, BruCON, etc. Mr. Siles is author of security training courses, blogs, books, articles, and tools, and actively contributes to community and open-source projects. He loves security challenges, and has been a member of international organisations, such as the Honeynet Project or the SANS Internet Storm Center. Raul is one of the few individuals worldwide who have earned the GIAC Security Expert (GSE) designation, as well as many other certifications. Raul holds a master's degree in computer science from UPM (Spain) and a postgraduate in security and e-commerce.

More information at http://www.raulsiles.com (@raullsiles) and http://www.dinosec.com (@dinosec).

OWASP Vulnerable Web Applications Directory Project

2013-11-19T21:51:44Z

Raul Siles: Fixed the link to OfflineOld

OWASP Vulnerable Web Applications Directory Project

2013-11-19T20:52:39Z

Raul Siles:

OWASP Zed Attack Proxy Project

2013-11-16T15:02:07Z

Raul Siles:

{{Social Media Links}}
= Main =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">
The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

''' Want to help us make ZAP even better for you? '''

''' Just fill in the ZAP User Questionnaire which is available in [https://docs.google.com/forms/d/1lUPTYHe9CS5tropNStoRK9jVeZ7tWRywhBHDIZjE4cA/viewform English], [https://docs.google.com/forms/d/1JhUdp4cxZ3qRayYWz3JHOLSP7DPdBI-zgnFzDWxbX5A/viewform French] and [https://docs.google.com/forms/d/1xAKE3TCOaBrmFnyAVUr6NdTd3mKvu7g_uGriOcS2Ka4/viewform Spanish]! '''

You can view the responses so far (which are separate for each languages) here: [https://docs.google.com/forms/d/1lUPTYHe9CS5tropNStoRK9jVeZ7tWRywhBHDIZjE4cA/viewanalytics English], [https://docs.google.com/forms/d/1JhUdp4cxZ3qRayYWz3JHOLSP7DPdBI-zgnFzDWxbX5A/viewanalytics French], [https://docs.google.com/forms/d/1xAKE3TCOaBrmFnyAVUr6NdTd3mKvu7g_uGriOcS2Ka4/viewanalytics Spanish]

[[Image:ZAP-Download.png | link=http://code.google.com/p/zaproxy/downloads/list]]

'''ZAP 2.2.2 is available via the above link!'''

'''For more details about 2.2.2 see the [http://code.google.com/p/zaproxy/wiki/HelpReleases2_2_2 release notes]'''

You can also get cross platform [http://code.google.com/p/zaproxy/wiki/WeeklyReleases weekly releases] which include all of the latest changes.

For a quick overview of ZAP and an introduction to version 2.0.0 see these tutorial videos on YouTube:

{{#ev:youtube|eH0RBI0nmww}} {{#ev:youtube|a-lJafBdAeM}}

For more videos see the links on the [https://code.google.com/p/zaproxy/wiki/Videos wiki videos page].

Interested in a ZAP talk or training event? See the [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project#tab=Talks talks] tab. Not one near you? Contact a [http://code.google.com/p/zaproxy/wiki/ZapEvangelists Zap Evangelist] to arrange one!

Want a very quick introduction? See the [https://www.owasp.org/index.php/File:owasp_zap_flyer_v2.pdf project pamphlet].

For a slightly longer introduction see the [http://www.owasp.org/images/c/c8/Conference_Style_slides_for_ZAP.ppt project presentation].

For more details about ZAP, including the full user guide, see the [https://code.google.com/p/zaproxy/wiki/Introduction wiki].

<paypal>Zed Attack Proxy</paypal>
</div>

= Screenshots =
[[Image:zap128x128.png|right]]
{|
|-
|
[[Image:ZAP-ScreenShotAddAlert.png||400px||ZAP Add Alert Screen Shot]]
|
[[Image:ZAP-ScreenShotHelp.png||400px|left|ZAP Help Screen Shot]]
|-
|
[[Image:ZAP-ScreenShotHistoryFilter.png|thumb|400px|left|ZAP History Filter Screen Shot]]
|
[[Image:ZAP-ScreenShotSearchTab.png|thumb|400px|left|ZAP Search Tab Screen Shot]]
|}

= Talks =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">
{{:Projects/OWASP Zed Attack Proxy Project/Pages/Talks | Talks}}

</div>
= News =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">
{{:Projects/OWASP Zed Attack Proxy Project/Pages/News | News}}

</div>
= ZAP Gear =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">

Yes, you can now buy ZAP related gear!

Its your chance to show your support for the project, c/o `CafePress`.

Click on the tshirt to enter the [http://www.cafepress.com/zaproxy ZAP Gear Store]:

[[Image:zap-tshirt-cp.PNG | link=http://www.cafepress.com/zaproxy]]

</div>
= Sponsors =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">

ZAP is developed by a worldwide [http://code.google.com/p/zaproxy/people/list team] of volunteers.

But we have also been helped by many organizations, either financially or by encouraging their employees to work on ZAP:

* [http://www.owasp.org OWASP]
* [http://www.mozilla.org Mozilla]
* [http://www.sage.co.uk Sage]
* [http://www.google.com Google]
* [http://www.microsoft.com Microsoft]
* [http://www.hacktics.com/ Hacktics, Ernst & Young]
* [http://www.dinosec.com/ DinoSec]
* [http://www.denimgroup.com Denim Group]
* [http://secureideas.net SecureIdeas]
* [http://utilisec.com UtiliSec]
* [http://www.encription.co.uk/ encription]
</div>
= Functionality =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">
'''Some of ZAP's functionality:'''

* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsIntercept Intercepting Proxy]
* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsSpider Traditional] and AJAX spiders
* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsAscan Automated scanner]
* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsPscan Passive scanner]
* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsBruteforce Forced browsing]
* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsFuzz Fuzzer]
* [http://code.google.com/p/zaproxy/wiki/HelpUiDialogsOptionsDynsslcert Dynamic SSL certificates]
* [http://code.google.com/p/zaproxy/wiki/SmartCards Smartcard and Client Digital Certificates support]
* [http://code.google.com/p/zaproxy/wiki/HelpAddonsWebsocketIntroduction Web sockets] support
* [http://code.google.com/p/zaproxy/wiki/HelpAddonsScriptsScripts Support for a wide range of scripting languages]
* [http://code.google.com/p/zaproxy/wiki/HelpAddonsPlugnhackPlugnhack Plug-n-Hack support]
* Authentication and session support
* [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsApi Powerful REST based API]
* Automatic updating option
* [https://code.google.com/p/zap-extensions/ Integrated and growing marketplace of add-ons]

</div>
= Features =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">
'''Some of ZAP's features:'''

* [http://www.apache.org/licenses/LICENSE-2.0 Open source]
* Cross platform
* Easy to install (just requires java 1.7)
* Completely free (no paid for 'Pro' version)
* Ease of use a priority
* [http://code.google.com/p/zaproxy/wiki/HelpIntro Comprehensive help pages]
* Fully internationalized
* Translated into over 20 languages
* Community based, with involvement actively encouraged
* Under active development by an international team of volunteers

ZAP is a fork of the well regarded [http://www.parosproxy.org/ Paros Proxy].

</div>
= Languages =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">

'''ZAP supports the following languages:'''

* English
* Arabic
* Bosnian
* Brazilian Portuguese
* Chinese
* Danish
* Filipino
* French
* German
* Greek
* Indonesian
* Italian
* Japanese
* Korean
* Persian
* Polish
* Russian
* Sinhala
* Spanish
* Urdu

You can use [http://crowdin.net/project/owasp-zap Crowdin] to help improve these translations or add new ones right now!

</div>
= Roadmap =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">

==Release 2.2.0==
ZAP 2.2.0 has been released, which includes:
* Support for scripts embedded in ZAP components like the active and passive scanners.
* Support for [https://blog.mozilla.org/security/2013/08/22/plug-n-hack/ Plug-n-Hack]
* Support for [https://developer.mozilla.org/en-US/docs/zest Mozilla Zest]
* Changes to support the 5 [http://code.google.com/p/zaproxy/wiki/GSoC2013 Google Summer of Code 2013] projects.

For more details see http://code.google.com/p/zaproxy/wiki/HelpReleases2_2_0

==Release 2.3.0==

The next release has not been scheduled yet.

Please fill in the User Questionnaire linked off the first tab - this will help us prioritize features for future releases.

</div>
= Get Involved =
[[Image:zap128x128.png|right]]
<div style="font-size:120%;border:none;margin: 0;color:#000">

Involvement in the development of ZAP is actively encouraged!

You do not have to be a security expert in order to contribute.

Some of the ways you can help:

==Feature Requests==

Please raise new feature requests as enhancement requests here: http://code.google.com/p/zaproxy/issues/list

If there are existing requests you are also interested in then please 'star' them - that way we can see which features people are most interested in and can prioritize them accordingly.

==Feedback==

Please use the [http://groups.google.com/group/zaproxy-users zaproxy-users Google Group] for feedback:
* What do like?
* What don't you like?
* What features could be made easier to use?
* How could the help pages be improved?

==Log issues==

Have you had a problem using ZAP?

If so and its not already been logged then please [http://code.google.com/p/zaproxy/issues/list report it]

==Localization==

Are you fluent in another language? Can you help translate ZAP into that language?

You can use [http://crowdin.net/project/owasp-zap Crowdin] to do that!

==Development==

If you fancy having a go at adding functionality to ZAP then please get in touch via the [http://groups.google.com/group/zaproxy-develop zaproxy-develop Google Group].

Again, you do not have to be a security expert to contribute code - working on ZAP could be great way to learn more about web application security!

If you actively contribute to ZAP then you will be invited to join the project.

</div>
= Project About =
<div style="font-size:120%;border:none;margin: 0;color:#000">
[[Image:zap128x128.png|right]]
{{:Projects/OWASP Zed Attack Proxy Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Zed Attack Proxy Project]] [[Category:OWASP_Tool]] [[Category:OWASP_Release_Quality_Tool|OWASP Release Quality Tool]] [[Category:OWASP_Download]]

User:Raul Siles

2013-11-16T15:00:23Z

Raul Siles:

Raul Siles is a founder and senior security analyst with DinoSec ([http://www.dinosec.com www.dinosec.com]). His more than 10 years of expertise performing advanced security services and solutions in various worldwide industries include security architecture design and reviews, penetration tests, incident handling, forensic analysis, security assessments, and information security research in new technologies, such as Web applications, wireless, honeynets, virtualization, mobile devices, and VoIP. Raul is one of the few individuals who have earned the GIAC Security Expert (GSE) designation. He is a SANS Institute author and instructor of penetration testing courses, a regular speaker at security conferences, author of security books and articles, and contributes to research and open-source projects. He loves security challenges, is a member of international organizations, such as the Honeynet Project, and is a handler for the Internet Storm Center (ISC). Raul holds a master's degree in computer science from UPM (Spain) and a postgraduate in security and e-commerce. More information can be found at http://www.raulsiles.com.

OWASP Vulnerable Web Applications Directory Project

2013-10-21T13:21:46Z

Raul Siles: Achim added to ACKs.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

Interview with [http://trustedsoftwarealliance.com/2013/10/18/simon-bennetts-the-owasp-web-applications-vulnerability-project/ Simon Bennetts – The OWASP Web Applications Vulnerability Project ].

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://github.com/sakti/twitterlike twitterlike ]
| PHP
| [https://github.com/sakti/twitterlike git repository]
| Sakti Dwi Cahyono
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
* [mailto:achim@owasp.org Achim Hoffmann]
* [[User:Zakiakhmad|Zaki Akhmad]]

==On-line resources used==
* [http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html Hacking Vulnerable Web Applications Without Going To Jail]
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]
* [http://code.google.com/p/owaspbwa/wiki/UserGuide OWASP BWA User Guide]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-20T06:10:09Z

Raul Siles: Interview with Simon added.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

Interview with [http://trustedsoftwarealliance.com/2013/10/18/simon-bennetts-the-owasp-web-applications-vulnerability-project/ Simon Bennetts – The OWASP Web Applications Vulnerability Project ].

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html Hacking Vulnerable Web Applications Without Going To Jail]
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]
* [http://code.google.com/p/owaspbwa/wiki/UserGuide OWASP BWA User Guide]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-20T06:08:47Z

Raul Siles: New references added to ACKs.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

TBA

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html Hacking Vulnerable Web Applications Without Going To Jail]
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]
* [http://code.google.com/p/owaspbwa/wiki/UserGuide OWASP BWA User Guide]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-20T06:01:54Z

Raul Siles:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

TBA

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum Project]
| Perl & PHP
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-20T06:00:45Z

Raul Siles: Cyclone transfers added

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

TBA

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum]
| PHP/Perl
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [https://github.com/fridaygoldsmith/bwa_cyclone_transfers Cyclone Transfers ]
| Ruby on Rails
|
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-20T05:58:30Z

Raul Siles:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

TBA

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum]
| PHP/Perl
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-20T05:56:16Z

Raul Siles: Vicnum added.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

The OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and especially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

The main goal of VWAD is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

TBA

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://vicnum.ciphertechs.com Vicnum]
| Perl
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-18T14:43:23Z

Raul Siles: Review and fixes.

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Vulnerable Web Applications Directory Project==

OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available.

==Introduction==

Select from the above tabs to view all of the:
* On-Line applications
* Off-Line applications
* Virtual Machines and ISO images

==Description==

OWASP Vulnerable Web Applications Directory (VWAD) Project is a comprehensive and well maintained registry of all known vulnerable web applications currently available. These vulnerable web applications can be used by web developers, security auditors and penetration testers to put in practice their knowledge and skills during training sessions (and specially afterwards), as well as to test at any time the multiple hacking tools and offensive techniques available, in preparation for their next real-world engagement.

VWAD main goal is to provide a list of vulnerable web applications available to security professionals for hacking and offensive activities, so that they can attack realistic web environments... without going to jail :)

The vulnerable web applications have been classified in three categories: On-Line, Off-Line, and VMs/ISOs. Each list has been ordered alphabetically.

An initial list that inspired this project was maintained till the end on 2013 at: http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html.

==Licensing==
OWASP Vulnerable Web Applications Directory Projects is free to use. It is licensed under the Apache 2.0 License, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is VWAD? ==

OWASP VWAD provides:

* A list of all known vulnerable web applications.

== Presentation ==

TBA

== Project Leaders ==

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

== Related Projects ==

* N/A

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* N/A - The project is self contained on the wiki.

== News and Events ==
* [16 Oct 2013] Project created.

== In Print ==
N/A

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=:Category:OWASP_Project#tab=Terminology]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-breakers-small.png|link=Breakers]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=On-Line apps=

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Author
! scope="col" | Notes
|-
| [http://testphp.vulnweb.com Acuart]
| PHP
| Acunetix
| Art shopping
|-
| [http://testaspnet.vulnweb.com/ Acublog]
| .NET
| Acunetix
| Blog
|-
| [http://testasp.vulnweb.com/ Acuforum]
| ASP
| Acunetix
| Forum
|-
| [http://demo.testfire.net/ Altoro Mutual]
|
| IBM/Watchfire
| (jsmith/Demo1234)
|-
| [http://crackme.cenzic.com/ Crack Me Bank]
|
| Cenzic
|
|-
| [http://enigmagroup.org/ Enigma Group]
|
| Enigma Group
|
|-
| [http://google-gruyere.appspot.com/ Gruyere]
| Python
| Google
|
|-
| [http://hackademic1.teilar.gr Hackademic Challenges Project]
| PHP - Joomla
| OWASP
|
|-
| [http://pctechtips.org/hacker-challenge-pwn3d-the-login-form/ Hacker Challenge]
|
| PCTechtips
|
|-
| [https://www.hacking-lab.com/events/registerform.html?eventid=245 Hacking Lab]
|
| Hacking Lab
|
|-
| [https://hack.me Hack.me]
|
| eLearnSecurity
| Beta
|-
| [http://www.hackthissite.org HackThisSite]
|
| HackThisSite
| Basic & Realistic (web) Missions
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
| First 2 levels online (algo/smurf), rest offline
|-
| [http://pentesteracademylab.appspot.com Pentester Academy]
|
|
|
|-
| [http://www.webscantest.com Web Scanner Test Site]
|
| NTOSpider
| (testuser/testpass)
|-
| [http://blasze.com/xsstestsuite/ XSS Test Suite]
|
|
|
|-
| [http://zero.webappsecurity.com/ Zero Bank]
|
| HP/SpiDynamics
| (admin/admin)
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

= Off-Line apps =

Vulnerable applications that have to be downloaded and used locally:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore]
| Perl(CGI)
|
|
|
|-
| [http://code.google.com/p/bodgeit/ BodgeIt Store ]
| Java
| [http://code.google.com/p/bodgeit/downloads/list download]
|
|
|-
| [http://sechow.com/bricks/index.html Bricks ]
| PHP
| [http://sechow.com/bricks/download.html download] [http://sechow.com/bricks/docs/ docs]
| OWASP
|
|-
| [http://sourceforge.net/projects/thebutterflytmp/files/ButterFly%20Project/ Butterfly Security Project]
| PHP
| [http://sourceforge.net/projects/thebutterflytmp/files/ download]
|
| Last updated in 2008
|-
| [http://www.itsecgames.com/ bWAPP ]
| PHP
| [http://sourceforge.net/projects/bwapp/files/ download] [http://itsecgames.blogspot.be/2013/01/bwapp-installation.html docs]
|
|
|-
| [http://www.dvwa.co.uk/ Damn Vulnerable Web Application - DVWA ]
| PHP
| [http://code.google.com/p/dvwa/downloads/list download]
| RandomStorm
|
|-
| [http://dvws.secureideas.net/ Damn Vulnerable Web Services - DVWS ]
| PHP
| [http://dvws.secureideas.net/downloads/files/dvws.tgz download]
| Secure Ideas
|
|-
| [http://google-gruyere.appspot.com/ Gruyere ]
| Python
| [http://google-gruyere.appspot.com/gruyere-code.zip download]
| Google
|
|-
| [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project Hackademic Challenges Project ]
| PHP
| [https://code.google.com/p/owasp-hackademic-challenges/ download]
| OWASP
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank-android.aspx Hacme Bank - Android]
|
|
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx Hacme Bank ]
| .NET
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-bank.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx Hacme Books ]
| Java
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmebooks.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx Hacme Casino ]
| Ruby on Rails
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacme-casino.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx Hacme Shipping ]
| ColdFusion
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmeshipping.aspx download]
| McAfee / Foundstone
|
|-
| [http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx Hacme Travel ]
| C++
| [http://www.mcafee.com/apps/free-tools/termsofuse.aspx?url=/us/downloads/free-tools/hacmetravel.aspx download]
| McAfee / Foundstone
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl hackxor]
|
|
|
| First 2 levels online, rest offline
|-
| [http://sourceforge.net/projects/lampsecurity/ LampSecurity]
| PHP
|
|
|
|-
| [http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Mutillidae ]
| PHP
| [http://www.irongeek.com/mutillidae/ download]
|
|
|-
| [https://owasp.codeplex.com/ .NET Goat ]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [http://peruggia.sourceforge.net/ Peruggia ]
| PHP
| [http://sourceforge.net/projects/peruggia/files/ download]
|
|
|-
| [https://code.google.com/p/puzzlemall/ Puzzlemall ]
| Java
| [https://code.google.com/p/puzzlemall/downloads/list download] [https://code.google.com/p/puzzlemall/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project Rails Goat ]
| Ruby on Rails
| [https://github.com/OWASP/railsgoat/archive/master.zip download] [http://railsgoat.cktricky.com/getting_started.html docs]
| OWASP
|
|-
| [http://suif.stanford.edu/%7Elivshits/securibench/ SecuriBench]
| Java
|
| Stanford
|
|-
| [http://suif.stanford.edu/%7Elivshits/work/securibench-micro/ SecuriBench Micro]
| Java
| [http://suif.stanford.edu/~livshits/securibench/download.html download]
| Stanford
|
|-
| [https://github.com/Audi-1/sqli-labs SQLI-labs]
| PHP
| [https://github.com/Audi-1/sqli-labs/archive/master.zip download] [http://dummy2dummies.blogspot.com/ blog]
|
|
|-
| [https://github.com/SpiderLabs/SQLol SQLol ]
| PHP
| [https://github.com/SpiderLabs/SQLol/archive/master.zip download]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project Vicnum Project ]
| Perl & PHP
| [http://sourceforge.net/projects/vicnum/files/ download]
| OWASP
|
|-
| [http://www.nth-dimension.org.uk/blog.php?id=88 VulnApp ]
| .NET
| [http://projects.nth-dimension.org.uk/dir?d=VulnApp CVS download] [http://projects.nth-dimension.org.uk/rptview?rn=6 vulns]
|
|
|-
| [http://exploit.co.il/hacking/exploit-kb-vulnerable-web-app/ Vulnerable Web App]
|
|
| Exploit.co.il
|
|-
| [https://github.com/adamdoupe/WackoPicko WackoPicko ]
| PHP
| [https://github.com/adamdoupe/WackoPicko/zipball/master download] [http://cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf whitepaper]
|
|
|-
| [https://code.google.com/p/wavsep/ Wavsep - Web Application Vulnerability Scanner Evaluation Project ]
| Java
| [https://code.google.com/p/wavsep/downloads/list download] [https://code.google.com/p/wavsep/downloads/list docs]
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project WebGoat ]
| Java
| [http://code.google.com/p/webgoat/downloads/list download] [https://www.owasp.org/index.php/WebGoat_User_and_Install_Guide_Table_of_Contents guide]
| OWASP
|
|-
| [https://owasp.codeplex.com/ WebGoat.NET]
| C#
| [https://owasp.codeplex.com/SourceControl/list/changesets# download]
| OWASP
|
|-
| [https://code.google.com/p/wivet/ WIVET - Web Input Vector Extractor Teaser]
|
| [http://www.webguvenligi.org/projeler/wivet download] [https://code.google.com/p/wivet/downloads/list?can=1&q= tests]
|
|
|-
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.mavensecurity.com/webmaven WebMaven/Buggy Bank]
|
|
|
|
|-
| [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project Insecure Web App Project ]
| Java
| [http://sourceforge.net/projects/insecurewebapp/files/ download]
| OWASP
|
|-
| [http://www.owasp.org/index.php/Owasp_SiteGenerator SiteGenerator]
| ASP.NET
|
| OWASP
|
|-
|}

= Virtual Machines or ISOs =

VMs which contain multiple vulnerable applications:

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
| [http://www.badstore.net/ BadStore ]
| ISO
| [http://www.badstore.net/register.htm download]
|
|
|-
| [http://sourceforge.net/projects/bwapp/files/bee-box/ Bee-Box ]
| bWAPP VMware
|
|
|
|-
| [http://code.google.com/p/owaspbwa/wiki/ProjectSummary Broken Web Applications Project (BWA) ]
| VMware
| [http://code.google.com/p/owaspbwa/wiki/Downloads download]
| OWASP
|
|-
| [https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ Drunk Admin Web Hacking Challenge ]
| VMware
| [http://bechtsoudis.com/data/challenges/drunk_admin_hacking_challenge.zip download]
|
|
|-
| [http://exploit.co.il/projects/vuln-web-app/ Exploit.co.il Vuln Web App ]
| VMware
| [http://sourceforge.net/projects/exploitcoilvuln/files/ download]
|
|
|-
| [http://sourceforge.net/projects/null-gameover/ GameOver ]
| VMware
| [http://sourceforge.net/projects/null-gameover/files/ download]
|
|
|-
| [http://hackxor.sourceforge.net/cgi-bin/index.pl Hackxor ]
| VMware
| [http://sourceforge.net/projects/hackxor/files/ download] [http://hackxor.sourceforge.net/cgi-bin/hints.pl hints&tips]
|
|
|-
| [http://ninja-sec.com/index.php/hacme-bank-prebuilt-vmware-image-ninja-sec-com/ Hacme Bank Prebuilt VM ]
| VMware
| [http://dc121.4shared.com/download/wwPhUxMQ/hackme_bank_vm_Ninja-Sec.zip download]
|
|
|-
| [http://www.kioptrix.com/blog/?p=604 Kioptrix4 ]
| VMware & Hyper-V
| [http://www.kioptrix.com/dlvm/Kioptrix4_vmware.rar download]
|
|
|-
| [http://sourceforge.net/projects/lampsecurity/ LAMPSecurity ]
| VMware
| [http://sourceforge.net/projects/lampsecurity/files/ download] [http://sourceforge.net/projects/lampsecurity/files/Documentation/ doc]
|
|
|-
| [http://blog.metasploit.com/2010/05/introducing-metasploitable.html Metasploitable ]
| VMware
| [http://updates.metasploit.com/data/Metasploitable.zip.torrent download] [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp doc]
|
|
|-
| [https://community.rapid7.com/docs/DOC-1875 Metasploitable 2 ]
| VMware
| [https://sourceforge.net/projects/metasploitable/files/Metasploitable2/ download]
|
|
|-
| [http://www.bonsai-sec.com/en/research/moth.php Moth ]
| VMware
| [http://sourceforge.net/projects/w3af/files/moth/moth/ download]
|
|
|-
| [https://www.pentesterlab.com/exercises/ PentesterLab - The Exercises ]
| ISO & PDF
|
|
|
|-
| [http://phdays.blogspot.com.es/2012/05/once-again-about-remote-banking.html PHDays I-Bank ]
| VMware
| [http://downloads.phdays.com/phdays_ibank_vm.zip download]
|
|
|-
| [http://www.samurai-wtf.org/ Samurai WTF ]
| ISO - list
| [http://sourceforge.net/projects/samurai/files/ download]
|
|
|-
| [http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html Sauron ]
| Quemu
| [http://sg6-labs.blogspot.com/search/label/SecGame solutions]
|
|
|-
| [http://sourceforge.net/projects/virtualhacking/ Virtual Hacking Lab ]
| ZIP
| [http://sourceforge.net/projects/virtualhacking/files/ download]
|
|
|-
| [http://www.mavensecurity.com/web_security_dojo/ Web Security Dojo ]
| VMware, VirtualBox
| [http://sourceforge.net/projects/websecuritydojo/files/ download]
|
|
|}

Please add any new apps in alphabetic order, correct mistakes or just comment on this page if you dont have write access to this wiki.

The following apps are quite old and appear not to be maintained - as such they are probably less useful.

{| border="1" width="80%" cellspacing="0" cellpadding="2"
|-
! scope="col" | App Name / Link
! scope="col" | Technology
! scope="col" | Other links
! scope="col" | Author
! scope="col" | Notes
|-
|-
| [http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp UltimateLAMP ]
| VMware
| [http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip download]
|
|
|}

= Acknowledgements =
==Volunteers==
VWAD is developed by a worldwide team of volunteers. The primary contributors to date have been:

*[mailto:raul@raulsiles.com Raul Siles]
*[[User:Simon Bennetts|Simon Bennetts]]

==Others==
*

==On-line resources used==
* [http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/ Vulnerable Web Applications for learning]

= Road Map and Getting Involved =
As of October 15, 2013, the priorities are:
* Document all known Vulnerable Web Applications
* Publicise
* Keep up to date
* Please add a more robust/descriptive roadmap.

Involvement in the development and promotion of the OWASP Vulnerable Web Applications Directory Project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* Update the wiki with any missing apps

=Project About=
{{:Projects/OWASP_Vulnerable_Web_Applications_Directory_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Breakers]] [[Category:OWASP_Document]]

OWASP Vulnerable Web Applications Directory Project

2013-10-16T10:31:27Z

Raul Siles: Description and minor adjustments.

Session Management Cheat Sheet

2013-02-12T23:12:09Z

Raul Siles: Added PopUp LogOut Firefox add-on.

= Introduction =

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or when cookies are not accepted due to user privacy concerns).

For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
* Web applications should make use of “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on the criticality of the web application and its data. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The later is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

'''NOTE''': Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements such as the PopUp LogOut Firefox add-on [9] allow conscious users to protect their sessions by helping to close them diligently.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to reauthenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged throughout cookies, as cookies are shared by all web browser tab/windows, but via a URL argument. 

== Automatic Client Logout ==

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, it is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustily defend against session attacks, they significantly increase the web application detection capabilities. A skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots), by using the same outbound web proxy (very common in corporate environments), or by modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that check the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

[8] '''HttpOnly Session ID in URL and Page Body | Cross Site Scripting''' http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

[9] '''PopUp LogOut Firefox add-on''' https://addons.mozilla.org/en-US/firefox/addon/popup-logout/ & http://popuplogout.iniqua.com

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Raul Siles - raul[at]taddong.com

[[Category:Cheatsheets]]

Spain/Projects/DNIe

2012-02-20T08:10:22Z

Raul Siles: Nuevas actividades DNIe-2 y DNIe-3 (y anuncio de 4-6)

== OWASP DNIe ==

El objetivo del proyecto OWASP DNIe es evaluar y mejorar la seguridad de las aplicaciones web que hacen uso del DNI electrónico (DNIe), documento nacional de identidad (DNI) electrónico en España, para la autenticación de usuarios, así como la posterior gestión de sesiones y controles de acceso, y para los procesos de creación y verificación de firma.

Dentro de las aplicaciones web que hacen un uso intensivo del DNIe para la identificador de usuarios, ciudadanos con identificación oficial en España, se encuentran tanto servicios proporcionados por la administración pública española y sus diferentes organismos (AAPP), como servicios y aplicaciones web de empresas y organizaciones privadas, donde destacan especialmente (pero no únicamente) los servicios de banca electrónica o servicios básicos (suministro de agua, electricidad, telecomunicaciones, etc).

El proyecto OWASP DNIe está compuesto por diferentes subproyectos o actividades cuyos objetivos principales (propuestos inicialmente) son identificar las tecnologías y los mecanismos más comúnmente utilizados en las aplicaciones web para interactuar con el DNIe, evaluar las vulnerabilidades más comunes en aplicaciones web que utilizan el DNIe para la autenticación de usuarios (incluyendo vulnerabilidades en la autenticación, gestión de sesiones y control de acceso de la aplicación web), evaluar las vulnerabilidades más comunes asociadas a los componentes cliente (applets Java y controles ActiveX) utilizados por las aplicaciones web que hacen uso del DNIe para la autenticación de usuarios y para la creación y verificación de firmas electrónicas ([http://www.dnielectronico.es/Preguntas_Frecuentes/auten_firm_elec/index.html avanzadas y reconocidas]), la creación y difusión de herramientas que faciliten la realización de auditorías, pruebas de intrusión y análisis de seguridad de aplicaciones web basadas en el DNIe, así como la publicación de una serie de mejores prácticas y recomendaciones de seguridad para el diseño y creación de aplicaciones web basadas en el DNIe.

== Subproyectos (o Actividades) ==

Los diferentes subproyectos o actividades se irán abordando en etapas independientes durante el 2011 y 2012, comenzando con la primera de las actividades (o subproyectos) del proyecto OWASP DNIe:

=== '''DNIe-1''': Identificación de los mecanismos y tecnologías de utilización y gestión del DNIe en aplicaciones web ===

* '''Fecha de inicio''': Junio 2011

* '''Descripción''': El propósito del primer subproyecto de OWASP DNIe, "Identificación de los mecanismos y tecnologías de utilización y gestión del DNIe en aplicaciones web" (DNIe-1), es recabar información de las tecnologías y mecanismos empleados para la creación de aplicaciones web basadas en el DNIe, a través de los responsables y/o personal involucrado en el diseño y programación de aplicaciones web basadas en el DNIe en España (jefes de proyecto, desarrolladores, arquitectos, administradores, consultores, profesionales de seguridad, etc).

* '''Objetivo''': El objetivo principal es identificar los entornos y tecnologías más comúnmente empleados para la gestión del DNIe en aplicaciones web y recopilar estadísticas y detalles sobre éstos. Esta información permitirá a la comunidad española de seguridad y de desarrollo de aplicaciones web conocer las diferentes alternativas tecnológicas disponibles y qué están siendo empleadas actualmente en entornos reales.

* '''Más información en DNIe-1: https://www.owasp.org/index.php/Spain/Projects/DNIe-1 '''

* '''Resultados''' (2011-12-09 - limitados): https://www.owasp.org/index.php/Spain/Projects/DNIe-1

=== '''DNIe-2''': Vulnerabilidades de seguridad en aplicaciones web basadas en el DNIe ===

* '''Fecha de inicio''': Febrero 2012

* '''Descripción''': El propósito del segundo subproyecto de OWASP DNIe, "Vulnerabilidades de seguridad en aplicaciones web basadas en el DNIe" (DNIe-2), es proporcionar información y detalles técnicos de las vulnerabilidades más comunes en aplicaciones web que utilizan el DNIe para la autenticación de usuarios, incluyendo vulnerabilidades en la autenticación, la gestión de sesiones y los controles de acceso de la aplicación web.

* '''Objetivo''': El objetivo principal es reflejar las vulnerabilidades más comunes en aplicaciones web que hacen uso del DNIe. El análisis se centra en vulnerabilidades de las aplicaciones web en tres áreas diferenciadas: autentificación, gestión de sesiones y controles de acceso, junto a su interacción con el protocolo HTTPS (SSL/TLS). Esta información permitirá a la comunidad española de seguridad y desarrollo de aplicaciones web conocer las vulnerabilidades y errores de seguridad presentes actualmente en entornos reales, y así poder evitarlas mediante la aplicación de las recomendaciones y mejores prácticas asociadas (qué serán detalladas en una actividad futura).

* '''Más información en DNIe-2: https://www.owasp.org/index.php/Spain/Projects/DNIe-2 '''

* '''Resultados''': <no publicados>

=== '''DNIe-3''': Vulnerabilidades de seguridad en los componentes cliente de las aplicaciones web basadas en el DNIe ===

* '''Fecha de inicio''': Febrero 2012

* '''Descripción''': El propósito del tercer subproyecto de OWASP DNIe, "Vulnerabilidades de seguridad en los componentes cliente de las aplicaciones web basadas en el DNIe" (DNIe-3), es proporcionar información y detalles técnicos de las vulnerabilidades más comunes en los componentes cliente (applets Java y controles ActiveX) de las aplicaciones web que utilizan el DNIe para la autenticación de usuarios, y para los procesos de creación y verificación de firmas.

* '''Objetivo''': El objetivo principal es reflejar las vulnerabilidades más comunes en los componentes cliente de las aplicaciones web que hacen uso del DNIe. El análisis se centra en todo tipo de vulnerabilidades en los componentes cliente (applets Java y controles ActiveX) de las aplicaciones web en dos áreas diferenciadas: vulnerabilidades que afectan a la interacción del componente cliente con la propia aplicación web y su funcionamiento, y vulnerabilidades adicionales del componente cliente que reducen la seguridad del dispositivo del usuario dónde han sido instalados. Esta información permitirá a la comunidad española de seguridad y desarrollo de aplicaciones web conocer las vulnerabilidades y errores de seguridad presentes actualmente en componentes cliente disponibles en entornos reales, y así poder evitarlas mediante la aplicación de las recomendaciones y mejores prácticas asociadas (qué serán detalladas en una actividad futura).

* '''Más información en DNIe-3: https://www.owasp.org/index.php/Spain/Projects/DNIe-3 '''

* '''Resultados''': <no publicados>

== Actividades futuras ==

=== '''DNIe-4''': Herramientas para la realización de auditorías de seguridad y pruebas de intrusión en aplicaciones web basadas en el DNIe ===

=== '''DNIe-5''': Recomendaciones y mejores prácticas frente a las vulnerabilidades de seguridad de las aplicaciones web basadas en el DNIe ===

=== '''DNIe-6''': Recomendaciones y mejores prácticas frente a las vulnerabilidades de seguridad de los componentes cliente de las aplicaciones web basadas en el DNI ===

== Miembros ==

El proyecto OWASP DNIe ha sido creado en Junio de 2011 por el capítulo español de OWASP (https://www.owasp.org/index.php/Spain) y es liderado por Raul Siles, Fundador y Analista de Seguridad de Taddong (http://www.taddong.com).

Cada una de las actividades o subproyectos de OWASP DNIe es liderada por diferentes investigadores:
* [https://www.owasp.org/index.php/Spain/Projects/DNIe-1 DNIe-1] y [https://www.owasp.org/index.php/Spain/Projects/DNIe-2 DNIe-2]: Raul Siles (raul.siles -AT- gmail.com)
* [https://www.owasp.org/index.php/Spain/Projects/DNIe-3 DNIe-3]: José A. Guasch (jaguasch -AT- gmail.com)

Spain/Projects/DNIe-3

2012-02-20T08:09:00Z

Raul Siles:

== '''DNIe-3: Vulnerabilidades de seguridad en los componentes cliente de las aplicaciones web basadas en el DNIe''' ==

* '''Fecha de inicio''': Febrero 2012

* '''Descripción''': El propósito del tercer subproyecto de OWASP DNIe, ''"Vulnerabilidades de seguridad en los componentes cliente de las aplicaciones web basadas en el DNIe"'' (DNIe-3), es proporcionar información y detalles técnicos de las vulnerabilidades más comunes en los componentes cliente (controles ActiveX y applets Java) de las aplicaciones web que utilizan el DNIe para la autenticación de usuarios, y para los procesos de creación y verificación de firmas.

* '''Objetivo''': El objetivo principal es reflejar las vulnerabilidades más comunes en los componentes cliente de las aplicaciones web que hacen uso del DNIe. El análisis se centra en todo tipo de vulnerabilidades en los componentes cliente (controles ActiveX y applets Java) de las aplicaciones web en dos áreas diferenciadas: vulnerabilidades que afectan a la interacción del componente cliente con la propia aplicación web y su funcionamiento, y vulnerabilidades adicionales del componente cliente que reducen la seguridad del sistema del usuario dónde han sido instalados. Esta información permitirá a la comunidad española de seguridad y desarrollo de aplicaciones web conocer las vulnerabilidades y errores de seguridad presentes actualmente en componentes cliente disponibles en entornos reales, y así poder evitarlas mediante la aplicación de las recomendaciones y mejores prácticas asociadas (qué serán detalladas en una actividad futura).

''NOTA'': Los resultados de estas vulnerabilidades han sido obtenidos tras la realización de diferentes actividades de investigación sobre los componentes cliente de aplicaciones web españolas que hacen uso del DNIe, tanto en el sector público (Administraciones Públicas o AAPP) como en el sector privado (financiero, seguros, infraestructuras, telecomunicaciones, etc).

* '''Alcance''': Esta actividad se centra en evaluar todo tipo de vulnerabilidades asociadas a los componentes clientes de las aplicaciones web que hacen uso del DNIe. Los componentes comúnmente utilizados, applets Java y controles ActiveX, pueden disponer tanto de capacidades de '''autentificación''' del usuario mediante el DNIe u otros certificados, como de '''creación y verificación de firma electrónica'''. Todos ellos se incluyen en esta actividad y serán objeto de análisis, independientemente de su funcionalidad.

* '''Resultados''': En primer lugar es necesario identificar la lista de componentes cliente utilizados habitualmente en las aplicaciones web que hacen uso del DNIe, tanto comerciales como gratuitos o de código abierto. La información de las vulnerabilidades de seguridad más comunes en aplicaciones web basadas en el DNIe serán publicadas en la página web del proyecto OWASP DNIe en forma de presentaciones, guías o documentos que ayuden a entender las debilidades y riesgos de seguridad de estas aplicaciones web. Adicionalmente, el proyecto facilitará a los investigadores de seguridad la publicación responsable de vulnerabilidades (''responsible full disclosure'') específicas existentes en componentes desarrollados por terceros.

* '''Participación''': El proyecto OWASP DNIe invita a la comunidad de seguridad y desarrollo de aplicaciones web que hacen uso del DNIe a participar en esta actividad, compartiendo sus conocimientos, vulnerabilidades identificadas, herramientas de auditoría, mejores prácticas para incrementar la seguridad de estas aplicaciones, etc, a través de la [https://lists.owasp.org/mailman/listinfo/owasp-spain lista de correo electrónico del capítulo español de OWASP], o contactando directamente con José A. Guasch (jaguasch -AT- gmail.com).

== '''RESULTADOS DNIe-3''': Vulnerabilidades de seguridad en los componentes cliente de las aplicaciones web basadas en el DNIe ==

''Próximamente...''

La seguridad de las aplicaciones web basadas en el DNIe será analizada durante la conferencia [https://www.rootedcon.es Rooted CON 2012] que se celebrará en Madrid del 1-3 de marzo de 2012, y en concreto en la ponencia [http://www.rootedcon.es/index.php/ponencias/ "Seguridad de aplicaciones web basadas en el DNIe"] impartida por Raúl Siles y José A. Guasch.

=== Listado de componentes cliente que hacen uso del DNIe ===

El listado que aparece a continuación se ha obtenido recopilando información de diversas fuentes, entre las que destacan:

* [https://zonatic.usatudni.es/es/aplicaciones/catalogo-de-aplicaciones.html Catálogo de aplicaciones que utilizan DNI-e en zonatic]
* [http://cert.inteco.es/solutionSearcher/Catalogo_STIC/Catalogo/Busqueda_de_Soluciones/?postAction=solutionSearchList&idSolutionCategory=1&solutionType=P Soluciones de Autenticación y certificación digital en Inteco]

{| class="wikitable" border="1"
|+ Componentes cliente para la realización de operaciones con DNI-e y certificados digitales (A-Z)
! Componente/Plataforma !! Fabricante
|-
| '''@firma''' || [http://www.mpt.es Ministerio de Política Territorial y Administración Pública]
|-
| '''Componente de la AEAT''' || [http://www.agenciatributaria.es Agencia Estatal de Administración Tributaria (AEAT)]
|-
| '''CryptoSign''' || [http://www.realsec.com/ Realsec]
|-
| '''eSigna WebSite''' || [http://www.indenova.com/ inDenova]
|-
| '''id@zki''' || [http://www.izenpe.com/ IZENPE]
|-
| '''OpenSignX (TrustedX)''' || [http://www.safelayer.com/es Safelayer Secure Communications, S.A.]
|-
| '''SIAVal (eAS/Trusted Signature Platform)''' || [http://www.sia.es/ Sistemas Informáticos Abiertos]
|-
| '''smartAPPLET''' || [http://www.bit4id.com/es/ bit4id Ibérica S.L.]
|-
| '''viafirma''' || [http://www.viafirma.com/ Viafirma S.L.]
|-
| '''WebSigner (ASF-Firma)''' || [http://www.tb-solutions.com/ TB-Solutions Advanced Technologies, S.L.]
|-
|}

=== Vulnerabilidades comunes en componentes cliente que hacen uso del DNIe ===

''...Próximamente...''

=== Vulnerabilidades específicas de componentes cliente que hacen uso del DNIe (''boletines de seguridad'') ===

''...Próximamente...''

== OWASP DNIe ==

Esta actividad o subproyecto (DNIe-3) forma parte del proyecto [https://www.owasp.org/index.php/Spain/Projects/DNIe OWASP DNIe].

Spain/Projects/DNIe-2

2012-02-20T08:08:32Z

Raul Siles:

== '''DNIe-2: Vulnerabilidades de seguridad en aplicaciones web basadas en el DNIe''' ==

* Fecha de inicio: Febrero 2012

* Descripción: El propósito del segundo subproyecto de OWASP DNIe, "Vulnerabilidades de seguridad en aplicaciones web basadas en el DNIe" (DNIe-2), es proporcionar información y detalles técnicos de las vulnerabilidades más comunes en aplicaciones web que utilizan el DNIe para la autenticación de usuarios, incluyendo vulnerabilidades en la autenticación, la gestión de sesiones y los controles de acceso de la aplicación web.

* Objetivo: El objetivo principal es reflejar las vulnerabilidades más comunes en aplicaciones web que hacen uso del DNIe. El análisis se centra en vulnerabilidades de las aplicaciones web en tres áreas diferenciadas (autentificación, gestión de sesiones y controles de acceso) y en su interacción con el protocolo HTTPS (SSL/TLS). Esta información permitirá a la comunidad española de seguridad y desarrollo de aplicaciones web conocer las vulnerabilidades y errores de seguridad presentes actualmente en entornos reales, y así poder evitarlas mediante la aplicación de las recomendaciones y mejores prácticas asociadas (qué serán detalladas en una actividad futura).

''NOTA'': Los resultados de estas vulnerabilidades han sido obtenidos tras la realización de numerosas pruebas de intrusión y auditorías web en aplicaciones web españolas que hacen uso del DNIe, tanto en el sector público (Administraciones Públicas o AAPP) como en el sector privado (financiero, seguros, infraestructuras, telecomunicaciones, etc).

* Alcance: Esta actividad se centra únicamente en las vulnerabilidades asociadas a los mecanismos de '''autentificación''' mediante el DNIe, donde el protocolo '''HTTPS''' juega un papel muy relevante, y en consecuencia, a los mecanismos de '''gestión de sesiones y control de acceso o autorización de los usuarios'''. Los mecanismos de '''creación y verificación de firma electrónica''' mediante el DNIe no se incluyen en esta actividad y serán analizados en actividades futuras del proyecto [https://www.owasp.org/index.php/Spain/Projects/DNIe OWASP DNIe].

* Resultados: La información de las vulnerabilidades de seguridad más comunes en aplicaciones web basadas en el DNIe serán publicadas en la página web del proyecto OWASP DNIe en forma de presentaciones, guías o documentos que ayuden a entender las debilidades y riesgos de seguridad de estas aplicaciones web.

* Participación: El proyecto OWASP DNIe invita a la comunidad de seguridad y desarrollo de aplicaciones web que hacen uso del DNIe a participar en esta actividad, compartiendo sus conocimientos, vulnerabilidades identificadas, herramientas de auditoría, mejores prácticas para incrementar la seguridad de estas aplicaciones, etc, a través de la [https://lists.owasp.org/mailman/listinfo/owasp-spain lista de correo electrónico del capítulo español de OWASP], o contactando directamente con Raul Siles (raul.siles -AT- gmail.com).

== '''RESULTADOS DNIe-2''': Vulnerabilidades de seguridad en aplicaciones web basadas en el DNIe ==

''Próximamente...''

La seguridad de las aplicaciones web basadas en el DNIe será analizada durante la conferencia [https://www.rootedcon.es RootedCON 2012] que se celebrará en Madrid del 1-3 de marzo de 2012, y en concreto en la ponencia [http://www.rootedcon.es/index.php/agenda/ "Seguridad de aplicaciones web basadas en el DNIe"] impartida por Raúl Siles y José A. Guasch.

=== Vulnerabilidades del protocolo HTTPS ===

''Próximamente...''

=== Vulnerabilidades de los mecanismos de registro y autentificación de usuarios mediante el DNIe ===

''Próximamente...''

=== Vulnerabilidades de los mecanismos de gestión de sesiones ===

''Próximamente...''

== OWASP DNIe ==

Esta actividad o subproyecto (DNIe-2) forma parte del proyecto [https://www.owasp.org/index.php/Spain/Projects/DNIe OWASP DNIe].