Norway

2015-05-09T20:34:28Z

Eoftedal: /* Medlemsmøte 7. mai kl 17:30 - D-Fens */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Brønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøter ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [http://www.meetup.com/OWASP-Norway/ meetup.com/OWASP-Norway/]. Påmelding finner du også der.
Det er anbefalt at du melder deg på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] slik at du får med deg oppdateringer og nyheter hos OWASP Norway.

Hvis du har noen tanker eller ideer til tema for medlemsmøter så har vi en [[Forslagskasse]] som du kan poste i. For å se hva vi har snakket om tidligere kan du se i [[#Tidligere år|medlemsmøtehistorikken]].

=== Neste møter ===

==== Medlemsmøte 7. mai kl 17:30 - D-Fens ====

'''Sted:''' Forskningsveien 3b, Oslo (se kart på meetup.com)

'''Påmelding:''' http://www.meetup.com/OWASP-Norway/events/221907724/ eller send epost til erlend.oftedal(æt)owasp.org

'''Agenda:''' http://www.meetup.com/OWASP-Norway/events/221907724/

Slides:

=== Tidligere møter ===

'''Generalforsamling'''

'''Tid''': Mandag 13.04.2015 '''Sted''': Mnemonic, Wergelandsveien 23

1. Valg av nytt styre for OWASP Norway

Følgende styre ble valgt ved akklamasjon:

Styreleder: Erlend Oftedal <erlend.oftedal@owasp.org> (Gjenvalg)

Kasserer: Kåre Presttun <kaare@mnemonic.no> (Gjenvalg)

Styremedlem: Audun Dragland <audun.dragland@computas.com> (Ny)

Styremedlem: Jostein Tveit <jostein.tveit@steria.no> (Ny)

Styremedlem: Asbjørn Thorsen <asbjoert@gmail.com> (Ny)

Styremedlem: Jon Are Rakvåg <jonare@jonare.no> (Ny)

Styremedlem: Åsmund Skomedal <asmund.skomedal@nr.no> (Ny)

Valgkomite:

Bjarte Østvold <bjarte@nr.no> (Ny)

Jøran Vanby Lillesand <joran.lillesand@bekk.no> (Ny)

Markus Harboe <markus.harboe@gmail.com> (Gjenvalg)

2. Eventuelt

Erlend presenterte Trello som et verktøy for styremedlemmene å organisere fremtidige medlemsmøter og foreslo Teknologihuset som fast møtested.

== Lokale nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2014]] ===
=== [[Medlemsmøter 2013]] ===
=== [[Medlemsmøter 2012]] ===
=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

Norway

2015-04-20T17:58:29Z

Eoftedal: /* Neste møter */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Brønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøter ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [http://www.meetup.com/OWASP-Norway/ meetup.com/OWASP-Norway/]. Påmelding finner du også der.
Det er anbefalt at du melder deg på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] slik at du får med deg oppdateringer og nyheter hos OWASP Norway.

Hvis du har noen tanker eller ideer til tema for medlemsmøter så har vi en [[Forslagskasse]] som du kan poste i. For å se hva vi har snakket om tidligere kan du se i [[#Tidligere år|medlemsmøtehistorikken]].

=== Neste møter ===

==== Medlemsmøte 7. mai kl 17:30 - D-Fens ====

'''Sted:''' Forskningsveien 3b, Oslo (se kart på meetup.com)

'''Påmelding:''' http://www.meetup.com/OWASP-Norway/events/221907724/ eller send epost til erlend.oftedal(æt)owasp.org

'''Agenda:''' [[http://www.meetup.com/OWASP-Norway/events/221907724/]]

=== Tidligere møter ===

'''Generalforsamling'''

'''Tid''': Mandag 13.04.2015 '''Sted''': Mnemonic, Wergelandsveien 23

1. Valg av nytt styre for OWASP Norway

Følgende styre ble valgt ved akklamasjon:

Styreleder: Erlend Oftedal <erlend.oftedal@owasp.org> (Gjenvalg)

Kasserer: Kåre Presttun <kaare@mnemonic.no> (Gjenvalg)

Styremedlem: Audun Dragland <audun.dragland@computas.com> (Ny)

Styremedlem: Jostein Tveit <jostein.tveit@steria.no> (Ny)

Styremedlem: Asbjørn Thorsen <asbjoert@gmail.com> (Ny)

Styremedlem: Jon Are Rakvåg <jonare@jonare.no> (Ny)

Styremedlem: Åsmund Skomedal <asmund.skomedal@nr.no> (Ny)

Valgkomite:

Bjarte Østvold <bjarte@nr.no> (Ny)

Jøran Vanby Lillesand <joran.lillesand@bekk.no> (Ny)

Markus Harboe <markus.harboe@gmail.com> (Gjenvalg)

2. Eventuelt

Erlend presenterte Trello som et verktøy for styremedlemmene å organisere fremtidige medlemsmøter og foreslo Teknologihuset som fast møtested.

== Lokale nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2014]] ===
=== [[Medlemsmøter 2013]] ===
=== [[Medlemsmøter 2012]] ===
=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

Norway

2015-04-15T12:05:55Z

Eoftedal: /* Tidligere møter */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Brønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøter ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [http://www.meetup.com/OWASP-Norway/ meetup.com/OWASP-Norway/]. Påmelding finner du også der.
Det er anbefalt at du melder deg på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] slik at du får med deg oppdateringer og nyheter hos OWASP Norway.

Hvis du har noen tanker eller ideer til tema for medlemsmøter så har vi en [[Forslagskasse]] som du kan poste i. For å se hva vi har snakket om tidligere kan du se i [[#Tidligere år|medlemsmøtehistorikken]].

=== Neste møter ===

=== Tidligere møter ===

'''Generalforsamling'''

'''Tid''': Mandag 13.04.2015 '''Sted''': Mnemonic, Wergelandsveien 23

1. Valg av nytt styre for OWASP Norway

Følgende styre ble valgt ved akklamasjon:

Styreleder: Erlend Oftedal <erlend.oftedal@owasp.org> (Gjenvalg)

Kasserer: Kåre Presttun <kaare@mnemonic.no> (Gjenvalg)

Styremedlem: Audun Dragland <audun.dragland@computas.com> (Ny)

Styremedlem: Jostein Tveit <jostein.tveit@steria.no> (Ny)

Styremedlem: Asbjørn Thorsen <asbjoert@gmail.com> (Ny)

Styremedlem: Jon Are Rakvåg <jonare@jonare.no> (Ny)

Styremedlem: Åsmund Skomedal <asmund.skomedal@nr.no> (Ny)

Valgkomite:

Bjarte Østvold <bjarte@nr.no> (Ny)

Jøran Vanby Lillesand <joran.lillesand@bekk.no> (Ny)

Markus Harboe <markus.harboe@gmail.com> (Gjenvalg)

2. Eventuelt

Erlend presenterte Trello som et verktøy for styremedlemmene å organisere fremtidige medlemsmøter og foreslo Teknologihuset som fast møtested.

== Lokale nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2014]] ===
=== [[Medlemsmøter 2013]] ===
=== [[Medlemsmøter 2012]] ===
=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

REST Security Cheat Sheet

2014-09-16T16:09:32Z

Eoftedal: /* Secure parsing */

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

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] (or REpresentational State Transfer) is a means of expressing specific entities in a system by URL path elements. REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URLs rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and session management =

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS; API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider using only the session token or API key to maintain client state in a server-side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time, and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt; change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in <tt>https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false</tt> as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.

== Whitelist allowable methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>PUT</tt> would update an existing entity, <tt>POST</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token-based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure direct object references ==

It may seem obvious, but if you had a bank account REST web service, you'd have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly absurd. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

Please make sure you understand how to protect against [[Top_10_2010-A4-Insecure_Direct_Object_References|insecure direct object references]] in the OWASP Top 10 2010.

= Input validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client-side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Secure parsing ==

Use a secure parser for parsing the incoming messages. If you are using XML, make sure to use a parser that is not vulnerable to [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing XXE] and similar attacks.

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate incoming content-types ==

When POSTing or PUTting new data, the client will specify the Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a <tt>406 Not Acceptable</tt> response.

== Validate response types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML input validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

= Output encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is preventing arbitrary JavaScript remote code execution within the browser... or, if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user-supplied data properly to prevent the execution of user-supplied input on the browser.

When inserting values into the browser DOM, strongly consider using <tt>.value</tt>/<tt>.innerText</tt>/<tt>.textContent</tt> rather than <tt>.innerHTML</tt> updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless the public information is completely read-only, the use of TLS should be mandated, particularly where credentials, updates, deletions, and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client-side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related articles =

{{Cheatsheet_Navigation}}

= Authors and primary editors =

Erlend Oftedal - erlend.oftedal@owasp.org 
Andrew van der Stock - vanderaj@owasp.org 
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

REST Security Cheat Sheet

2014-09-16T16:07:18Z

Eoftedal: /* Insecure firect object references */

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

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] (or REpresentational State Transfer) is a means of expressing specific entities in a system by URL path elements. REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URLs rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and session management =

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS; API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider using only the session token or API key to maintain client state in a server-side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time, and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt; change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in <tt>https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false</tt> as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.

== Whitelist allowable methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>PUT</tt> would update an existing entity, <tt>POST</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token-based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure direct object references ==

It may seem obvious, but if you had a bank account REST web service, you'd have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly absurd. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

Please make sure you understand how to protect against [[Top_10_2010-A4-Insecure_Direct_Object_References|insecure direct object references]] in the OWASP Top 10 2010.

= Input validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client-side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Secure parsing ==

Use a secure parser for parsing the incoming messages. If you are using XML, make sure to use a parser that is not vulnerable to [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing XXE attacks].

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate incoming content-types ==

When POSTing or PUTting new data, the client will specify the Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a <tt>406 Not Acceptable</tt> response.

== Validate response types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML input validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

= Output encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is preventing arbitrary JavaScript remote code execution within the browser... or, if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user-supplied data properly to prevent the execution of user-supplied input on the browser.

When inserting values into the browser DOM, strongly consider using <tt>.value</tt>/<tt>.innerText</tt>/<tt>.textContent</tt> rather than <tt>.innerHTML</tt> updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless the public information is completely read-only, the use of TLS should be mandated, particularly where credentials, updates, deletions, and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client-side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related articles =

{{Cheatsheet_Navigation}}

= Authors and primary editors =

Erlend Oftedal - erlend.oftedal@owasp.org 
Andrew van der Stock - vanderaj@owasp.org 
| valign="top" style="padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;" |

== Other cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Norway

2014-06-12T09:29:07Z

Eoftedal: /* Medlemsmøte: 7. Februar, kl 17:00 */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Bønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøter ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [http://www.meetup.com/OWASP-Norway/ meetup.com/OWASP-Norway/]. Påmelding finner du også der

Hvis du ikke er på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] så meld deg på!

=== Tidligere møter ===

[[Forslagskasse]] for tema

=== Neste møte ===

==== Medlemsmøte: 26. Juni, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/188627202/ Påmelding på meetup.com]]
'''Tema:''' Hacking with Unicode

==== Medlemsmøte: 7. Februar, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/98525562/ Påmelding på meetup.com]]
'''Tema:''' Crossing Domains by Crossing Origins

==== Medlemsmøte: 18. Oktober, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/84322982/ Påmelding på meetup.com]]
'''Tema:''' Sikkerhet i det norske eValg-systemet

==== Medlemsmøte: 24. april, kl 19:30 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' -,
'''Adresse:''' [http://maps.google.com/maps?q=Tordenskiolds+gate+3%2C+Oslo Mesh Norway, Tordenskiolds gate 3],
'''Påmelding:''' [http://www.doodle.com/t7kaxy7a5u7v6u6s klikk her]

Tema denne gang er sikkerhet i mobile applikasjoner. Det blir først en introduksjon, deretter kommer
Martin Knobloch fra OWASP Nederland for å snakke om iGoat og GoatDroid, for så å dele erfaringer fra
en code review.

Slides:

[[Media:Mobil - Introduksjon til applikasjonssikkerhet.pdf|OWASP Mobile Top 10]] - Ståle Pettersen

[[Media:OWASP-mobile aps.pdf|OWASP Mobile]] - Martin Knobloch

==== Medlemsmøte: 19. mars, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' F5,
'''Adresse:''' [http://maps.google.com/maps?q=the+dubliner+oslo&hl=en&client=ubuntu&channel=fs&fb=1&hq=the+dubliner&hnear=0x46416e61f267f039:0x7e92605fd3231e9a,Oslo,+Norway&cid=0,0,12890284609415510924&t=h&z=15&iwloc=A The Dubliner],
'''Påmelding:''' [http://www.doodle.com/d4rfandvnakqydc6 klikk her]
{|
|'''"Web Application Access Control Design Excellence"''', Jim Manico 

Access Control is a necessary security control at almost every layer within a web application. This talk will discuss
several of the key access control anti-patterns commonly found during website security audits. These access control anti-patterns
include hard-coded security policies, lack of horizontal access control, and "fail open" access control mechanisms. In reviewing
these and other access control problems, we will discuss and design a positive access control mechanism that is data contextual,
activity based, configurable, flexible, and deny-by-default - among other positive design attributes that make up a robust
web-based access-control mechanism.
|}

== Lokale Nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

Norway

2014-02-25T10:51:34Z

Eoftedal: /* Medlemsmøte */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Bønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøter ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [http://www.meetup.com/OWASP-Norway/ meetup.com/OWASP-Norway/]. Påmelding finner du også der

Hvis du ikke er på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] så meld deg på!

=== Tidligere møter ===

[[Forslagskasse]] for tema

=== Neste møte ===

==== Medlemsmøte: 7. Februar, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/98525562/ Påmelding på meetup.com]]
'''Tema:''' Crossing Domains by Crossing Origins

==== Medlemsmøte: 18. Oktober, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/84322982/ Påmelding på meetup.com]]
'''Tema:''' Sikkerhet i det norske eValg-systemet

==== Medlemsmøte: 24. april, kl 19:30 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' -,
'''Adresse:''' [http://maps.google.com/maps?q=Tordenskiolds+gate+3%2C+Oslo Mesh Norway, Tordenskiolds gate 3],
'''Påmelding:''' [http://www.doodle.com/t7kaxy7a5u7v6u6s klikk her]

Tema denne gang er sikkerhet i mobile applikasjoner. Det blir først en introduksjon, deretter kommer
Martin Knobloch fra OWASP Nederland for å snakke om iGoat og GoatDroid, for så å dele erfaringer fra
en code review.

Slides:

[[Media:Mobil - Introduksjon til applikasjonssikkerhet.pdf|OWASP Mobile Top 10]] - Ståle Pettersen

[[Media:OWASP-mobile aps.pdf|OWASP Mobile]] - Martin Knobloch

==== Medlemsmøte: 19. mars, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' F5,
'''Adresse:''' [http://maps.google.com/maps?q=the+dubliner+oslo&hl=en&client=ubuntu&channel=fs&fb=1&hq=the+dubliner&hnear=0x46416e61f267f039:0x7e92605fd3231e9a,Oslo,+Norway&cid=0,0,12890284609415510924&t=h&z=15&iwloc=A The Dubliner],
'''Påmelding:''' [http://www.doodle.com/d4rfandvnakqydc6 klikk her]
{|
|'''"Web Application Access Control Design Excellence"''', Jim Manico 

Access Control is a necessary security control at almost every layer within a web application. This talk will discuss
several of the key access control anti-patterns commonly found during website security audits. These access control anti-patterns
include hard-coded security policies, lack of horizontal access control, and "fail open" access control mechanisms. In reviewing
these and other access control problems, we will discuss and design a positive access control mechanism that is data contextual,
activity based, configurable, flexible, and deny-by-default - among other positive design attributes that make up a robust
web-based access-control mechanism.
|}

== Lokale Nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

Norway

2014-02-25T10:51:26Z

Eoftedal: /* Medlemsmøte */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Bønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøte ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [http://www.meetup.com/OWASP-Norway/ meetup.com/OWASP-Norway/]. Påmelding finner du også der

Hvis du ikke er på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] så meld deg på!

=== Tidligere møter ===

[[Forslagskasse]] for tema

=== Neste møte ===

==== Medlemsmøte: 7. Februar, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/98525562/ Påmelding på meetup.com]]
'''Tema:''' Crossing Domains by Crossing Origins

==== Medlemsmøte: 18. Oktober, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/84322982/ Påmelding på meetup.com]]
'''Tema:''' Sikkerhet i det norske eValg-systemet

==== Medlemsmøte: 24. april, kl 19:30 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' -,
'''Adresse:''' [http://maps.google.com/maps?q=Tordenskiolds+gate+3%2C+Oslo Mesh Norway, Tordenskiolds gate 3],
'''Påmelding:''' [http://www.doodle.com/t7kaxy7a5u7v6u6s klikk her]

Tema denne gang er sikkerhet i mobile applikasjoner. Det blir først en introduksjon, deretter kommer
Martin Knobloch fra OWASP Nederland for å snakke om iGoat og GoatDroid, for så å dele erfaringer fra
en code review.

Slides:

[[Media:Mobil - Introduksjon til applikasjonssikkerhet.pdf|OWASP Mobile Top 10]] - Ståle Pettersen

[[Media:OWASP-mobile aps.pdf|OWASP Mobile]] - Martin Knobloch

==== Medlemsmøte: 19. mars, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' F5,
'''Adresse:''' [http://maps.google.com/maps?q=the+dubliner+oslo&hl=en&client=ubuntu&channel=fs&fb=1&hq=the+dubliner&hnear=0x46416e61f267f039:0x7e92605fd3231e9a,Oslo,+Norway&cid=0,0,12890284609415510924&t=h&z=15&iwloc=A The Dubliner],
'''Påmelding:''' [http://www.doodle.com/d4rfandvnakqydc6 klikk her]
{|
|'''"Web Application Access Control Design Excellence"''', Jim Manico 

Access Control is a necessary security control at almost every layer within a web application. This talk will discuss
several of the key access control anti-patterns commonly found during website security audits. These access control anti-patterns
include hard-coded security policies, lack of horizontal access control, and "fail open" access control mechanisms. In reviewing
these and other access control problems, we will discuss and design a positive access control mechanism that is data contextual,
activity based, configurable, flexible, and deny-by-default - among other positive design attributes that make up a robust
web-based access-control mechanism.
|}

== Lokale Nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

Norway

2014-02-25T10:50:36Z

Eoftedal: /* Medlemsmøter */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Bønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøte ==

Fremtidige medlemsmøter blir annonsert på mailinglista og på [[http://www.meetup.com/OWASP-Norway/ meetup.com]]. Påmelding finner du også der

Hvis du ikke er på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] så meld deg på!

=== Tidligere møter ===

[[Forslagskasse]] for tema

=== Neste møte ===

==== Medlemsmøte: 7. Februar, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/98525562/ Påmelding på meetup.com]]
'''Tema:''' Crossing Domains by Crossing Origins

==== Medlemsmøte: 18. Oktober, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/84322982/ Påmelding på meetup.com]]
'''Tema:''' Sikkerhet i det norske eValg-systemet

==== Medlemsmøte: 24. april, kl 19:30 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' -,
'''Adresse:''' [http://maps.google.com/maps?q=Tordenskiolds+gate+3%2C+Oslo Mesh Norway, Tordenskiolds gate 3],
'''Påmelding:''' [http://www.doodle.com/t7kaxy7a5u7v6u6s klikk her]

Tema denne gang er sikkerhet i mobile applikasjoner. Det blir først en introduksjon, deretter kommer
Martin Knobloch fra OWASP Nederland for å snakke om iGoat og GoatDroid, for så å dele erfaringer fra
en code review.

Slides:

[[Media:Mobil - Introduksjon til applikasjonssikkerhet.pdf|OWASP Mobile Top 10]] - Ståle Pettersen

[[Media:OWASP-mobile aps.pdf|OWASP Mobile]] - Martin Knobloch

==== Medlemsmøte: 19. mars, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' F5,
'''Adresse:''' [http://maps.google.com/maps?q=the+dubliner+oslo&hl=en&client=ubuntu&channel=fs&fb=1&hq=the+dubliner&hnear=0x46416e61f267f039:0x7e92605fd3231e9a,Oslo,+Norway&cid=0,0,12890284609415510924&t=h&z=15&iwloc=A The Dubliner],
'''Påmelding:''' [http://www.doodle.com/d4rfandvnakqydc6 klikk her]
{|
|'''"Web Application Access Control Design Excellence"''', Jim Manico 

Access Control is a necessary security control at almost every layer within a web application. This talk will discuss
several of the key access control anti-patterns commonly found during website security audits. These access control anti-patterns
include hard-coded security policies, lack of horizontal access control, and "fail open" access control mechanisms. In reviewing
these and other access control problems, we will discuss and design a positive access control mechanism that is data contextual,
activity based, configurable, flexible, and deny-by-default - among other positive design attributes that make up a robust
web-based access-control mechanism.
|}

== Lokale Nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

REST Assessment Cheat Sheet

2013-11-04T20:06:01Z

Eoftedal: /* How to pen test a RESTful web service? */

= About RESTful Web Services =

Web Services are an implementation of web technology used for machine to machine communication. As such they are used for Inter application communication, Web 2.0 and Mashups and by desktop and mobile applications to call a server. RESTful web services (often called simply REST) are a light weight variant of Web Services based on the RESTful design pattern. In practice RESTful web services utilizes HTTP requests that are similar to regular HTTP calls in contrast with other Web Services technologies such as SOAP which utilizes a complex protocol.

= Key relevant properties of RESTful web services =
* Use of HTTP methods (GET, POST, PUT and DELETE) as the primary verb for the requested operation.
* None standard parameters specifications:
** As part of the URL
** In headers
* Structured parameters and responses using JSON or XML in a parameter values, request body or response body. Those are required to communicate machine useful information.
* Custom authentication and session management, often utilizing custom security tokens: this is needed as machine to machine communication does not allow for login sequences.
* Lack of formal documentation. A proposed standard for describing RESTful web services called WADL was never officially adapted.

= The challenge of security testing RESTful web services =
* Inspecting the application does not reveal the attack surface, I.e. the URLs and parameter structure used by the RESTful web service. The reasons are:
** No application utilizes all the available functions and parameters exposed by the service
** Those used are often activated dynamically by client side code and not as links in pages.
** The client application is often not a web application and does not allow inspection of the activating link or even relevant code.
* The parameters are none standard making it hard to determine what is just part of the URL or a constant header and what is a parameter worth fuzzing.
* As a machine interface the number of parameters used can be very large, for example a JSON structure may include dozens of parameters. Fuzzing each one significantly lengthen the time required for testing.
* Custom authentication mechanisms require reverse engineering and make popular tools not useful as they cannot track a login session.

= How to pen test a RESTful web service? =
; Determine the attack surface through documentation - RESTful pen testing might be better off if some level of white box testing is allowed and you can get information about the service. This information will ensure fuller coverage of the attack surface. Such information to look for:
* Formal service description - While for other types of web services such as SOAP a formal description, usually in WSDL is often available, this is seldom the case for REST. That said, either WSDL 2.0 or WADL can describe REST and are sometimes used.
* A developer guide for using the service may be less detailed but will commonly be found, and might even be considered "black box"
* Application source or configuration - in many frameworks, including dotNet ,the REST service definition might be easily obtained from configuration files rather than from code.

; Collect full requests using a proxy - while always an important pen testing step, this is more important for REST based applications as the application UI may not give clues on the actual attack surface. Note that the proxy must be able to collect full requests and not just URLs as REST services utilize more than just GET parameters.

; Analyze collected requests to determine the attack surface:
* Look for non-standard parameters:
** Look for abnormal HTTP headers - those would many times be header based parameters.
** Determine if a URL segment has a repeating pattern across URLs. Such patterns can include a date, a number or an ID like string and indicate that the URL segment is a URL embedded parameter. For example: http://server/srv/2013-10-21/use.php
** Look for structured parameter values - those may be JSON, XML or a non-standard structure.
** If the last element of a URL does not have an extension, it may be a parameter. This is especially true if the application technology normally uses extensions or if a previous segment does have an extension. For example: http://server/svc/Grid.asmx/GetRelatedListItems
** Look for highly varying URL segments - a single URL segment that has many values may be parameter and not a physical directory. For example if the URL http://server/src/XXXX/page repeats with hundreds of value for XXXX, chances XXXX is a parameter.
; Verify non-standard parameters: in some cases (but not all), setting the value of a URL segment suspected of being a parameter to a value expected to be invalid can help determine if it is a path elements of a parameter. If a path element, the web server will return a 404 message, while for an invalid value to a parameter the answer would be an application level message as the value is legal at the web server level.

; Analyzing collected requests to optimize fuzzing - after identifying potential parameters to fuzz, analyze the collected values for each to determine -
* Valid vs. invalid values, so that fuzzing can focus on marginal invalid values. For example sending "0" for a value found to be always a positive integer.
* Sequences allowing to fuzz beyond the range presumably allocated to the current user.

; Lastly, when fuzzing, don't forget to emulate the authentication mechanism used.

= Related Resources =
* [[REST Security Cheat Sheet]] - the other side of this cheat sheet 
* [http://www.xiom.com/2011/11/20/restful_webservices_testing RESTful services, web security blind spot] - a presentation (including video) elaborating on most of the topics on this cheat.

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Ofer Shezaf - ofer@shezaf.com 

[[Category:Cheatsheets]]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T05:50:32Z

Eoftedal: /* References */

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext ''<tt>p</tt>'' and a cipher with a block size ''<tt>n</tt>'', the number of blocks will be ''<tt>b = ceil( length(b) / n)</tt>''. The length of the encrypted string will be ''<tt>y=(b+1)*n</tt>'' due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the second-to-last block ''<tt>b-1</tt>'' (the least significant bit of the byte at ''<tt>y-n-1</tt>''), re-encode and send. Next, decode the original string, flip the last bit of the block ''<tt>b-2</tt>'' (the least significant bit of the byte at ''<tt>y-2*n-1</tt>''), re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]
 
'''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T05:50:05Z

Eoftedal: /* Black Box testing and example */

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext ''<tt>p</tt>'' and a cipher with a block size ''<tt>n</tt>'', the number of blocks will be ''<tt>b = ceil( length(b) / n)</tt>''. The length of the encrypted string will be ''<tt>y=(b+1)*n</tt>'' due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the second-to-last block ''<tt>b-1</tt>'' (the least significant bit of the byte at ''<tt>y-n-1</tt>''), re-encode and send. Next, decode the original string, flip the last bit of the block ''<tt>b-2</tt>'' (the least significant bit of the byte at ''<tt>y-2*n-1</tt>''), re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]
 
''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T05:47:24Z

Eoftedal: /* Black Box testing and example */

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext ''<tt>p</tt>'' and a cipher with a block size ''<tt>n</tt>'', the number of blocks will be ''<tt>b = ceil( length(b) / n)</tt>''. The length of the encrypted string will be ''<tt>(b+1)*n</tt>'' due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the second-to-last block (the last bit of block ''<tt>b-1</tt>''), re-encode and send. Next, decode the original string, flip the last bit of the block ''<tt>b-2</tt>'', re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]
 
''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T05:40:29Z

Eoftedal: /* Black Box testing and example */

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext p and a cipher with a block size n, the number of blocks will be b = ceil( length(b) / n). The length of the encrypted string will be (b+1)*n due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the second-to-last block (the last bit of block b), re-encode and send. Next, decode the original string, flip the last bit of the block b - 1, re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]
 
''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T05:39:20Z

Eoftedal: /* References */

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext p and a cipher with a block size n, the number of blocks will be b = ceil( length(b) / n). The length of the encrypted string will be (b+1)*n due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the string (the last bit of block b+1), re-encode and send. Next, decode the original string, flip the last bit of the second to last block (block b), re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]
 
''Examples''' 
* Visualization of the decryption process - [http://erlend.oftedal.no/blog/poet/]

Testing for Padding Oracle (OTG-CRYPST-002)

2013-09-12T05:36:36Z

Eoftedal: /* Black Box testing and example */

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
A padding oracle is a function of an application which decrypts encrypted data provided by the client, e.g. internal session state stored on the client, and leaks the state of the validity of the padding after decryption. The existence of a padding oracle allows an attacker to decrypt encrypted data and encrypt arbitrary data without knowledge of the key used for these cryptographic operations. This can lead to leakage of sensible data or to privilege escalation vulnerabilities, if integrity of the encrypted data is assumed by the application.
 
== Description of the Issue ==
 
Block ciphers encrypt data only in blocks of certain sizes. Block sizes used by common ciphers are 8 and 16 bytes. Data where the size doesn't matches a multiple of the block size of the used cipher has to be padded in a manner, that the decryptor is able to strip the padding. A commonly used padding scheme is PKCS#7. It fills the remaining bytes with the value of the padding length.

'''Example:''' if the padding has the length of 5 bytes, the byte value 0x05 is repeated five times after the plain text.

An error condition is present, if the padding doesn't matches the syntax of the used padding scheme. A padding oracle is present, if an application leaks this specific padding error condition for encrypted data provided by the client. This can happen by exposing exceptions (e.g. BadPaddingException in Java) directly, by subtle differences in the responses sent to the client or by another side-channel like timing behavior.

Certain modes of operation of cryptography allow bit-flipping attacks, where flipping of a bit in the cipher text causes that the bit is also flipped in the plain text. Flipping a bit in the n-th block of CBC encrypted data causes that the same bit in the (n+1)-th block is flipped in the decrypted data. The n-th block of the decrypted cipher text is garbaged by this manipulation.

The padding oracle attack enables an attacker to decrypt encrypted data without knowledge of the encryption key and used cipher by adaptively sending skillful manipulated cipher texts to the padding oracle and observing of the results returned by it. This causes loss of confidentiality of the encrypted data. E.g. in the case of session data stored on the client side the attacker can gain information about the internal state and structure of the application. A padding oracle attack also enables an attacker to encrypt arbitrary plain texts without knowledge of the used key and cipher. If the application assumes that integrity and authenticity of the decrypted data is given, an attacker could be able to manipulate internal session state and possibly gain higher privileges.
 
== Black Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
First, possible input points for padding oracles must be identified. Generally the following conditions must be met:

# The data is encrypted. Good candidates are values which appear to be random.
# A block cipher is used. The length of the decoded (Base64 is used often) cipher text is a multiple of common cipher block sizes like 8 or 16 bytes. Different cipher texts (e.g. gathered by different sessions or manipulation of session state) share a common divisor in the length.

'''Example:''' <nowiki>Dg6W8OiWMIdVokIDH15T/A==</nowiki> results after Base64 decoding in 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. This seems to be random and 16 byte long.

If such an input value candidate is identified, the behavior of the application to bit-wise tampering of the encrypted value should be verified. Normally this Base64 encoded value will include the initialization vector (IV) prepended to the cipher text. Given a plaintext p and a cipher with a block size n, the number of blocks will be b = ceil( length(b) / n). The length of the encrypted string will be (b+1)*n due to the initialization vector. To verify the precense of the oracle, decode the string, flip the last bit of the string (the last bit of block b+1), re-encode and send. Next, decode the original string, flip the last bit of the second to last block (block b), re-encode and send.

If it's known that the encrypted string is a single block (the IV is stored on the server or the application is using a bad practice hardcoded IV), several bit flips must be performed in turn. An alternative approach could be to prepend a random block, and flip bits in order to make the last byte of the added block take all possible values (0 to 255).

The tests and the base value should at least cause three different states while and after decryption:

* Cipher text gets decrypted, resulting data is correct.
* Cipher text gets decrypted, resulting data is garbled and causes some exception or error handling in the application logic.
* Cipher text decryption fails due to padding errors.

Compare the responses carefully. Search especially for exceptions and messages which state that something is wrong with the padding. If such messages appear, the application contains a padding oracle. If the three different states described above are observable implicitly (different error messages, timing side-channels), there is a high probability, that there is a padding oracle present at this point. Try to perform the padding oracle attack to ensure this.

'''Examples:'''
* ASP.NET throws "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed." if padding of a decrypted cipher text is broken.
* In Java a javax.crypto.BadPaddingException is thrown in this case.
* Decryption errors or similar can be possible padding oracles.
 
'''Result Expected:''' 
A secure implementation will check for integrity and cause only two responses: ok and failed. There are no side channels which can be used to determine internal error states.
 

== White Box testing and example ==
'''Testing for padding oracle vulnerabilities:''' 
Verify all places where encrypted data from the client, that should only be known by the server, is decrypted. The following conditions should be met by such code:

# The integrity of the cipher text should be verified by a secure mechanism which uses a different secret than the encryption and decryption of the cipher text.
# All error states while decryption and further processing are handled uniformly.
== References ==
'''Whitepapers''' 
* Wikipedia - Padding oracle attack - [http://en.wikipedia.org/wiki/Padding_oracle_attack]
* Juliano Rizzo, Thai Duong, "Practical Padding Oracle Attacks" - [http://www.usenix.org/event/woot10/tech/full_papers/Rizzo.pdf]
 
'''Tools''' 
* PadBuster - [https://github.com/GDSSecurity/PadBuster]
* Poracle - [https://github.com/iagox86/Poracle]
* Padding Oracle Exploitation Tool (POET) - [http://netifera.com/research/]

REST Security Cheat Sheet

2013-08-22T22:28:07Z

Eoftedal: /* Input Validation */

= Introduction =

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] or REpresentational State Transfer is a means of expressing specific entities in a system by URL path elements, REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URL's rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and Session Management =

RESTful web services should use session based authentication, either by establishing a session token via a POST, or using an API key as a POST body argument or as a cookie. Usernames and passwords, session tokens and API keys should not appear in the URL, as this can be captured in web server logs and makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS and API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider just using the session token or API key to maintain client state in a server side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt and change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry, whereas for the librarian, both of these are valid uses.

== Whitelist Allowable Methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>POST</tt> would update an existing entity, <tt>PUT</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs will work, all others return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure Direct object references ==

It may seem obvious, but if you had a bank account REST web service, you have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly insane. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

Please make sure you understand how to protect against [[Top_10_2010-A4-Insecure_Direct_Object_References|insecure direct object references]] in the OWASP Top 10 2010.

= Input Validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Secure parsing ==

Use a secure parser for parsing the incoming messages. If you are using XML, make sure to use a parser that is not vulnerable to [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing XEE attacks].

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate Incoming Content-Types ==

When POSTing or PUTing new data, the client will specify the a Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type, but always check that the Content-Type header and the content is of the same type. A lack of Content-Type header or an unexpected Content-Type header, should result in the server rejecting the Content with a <tt>406 Not Acceptable</tt> response.

== Validate Response Types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML Input Validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

= Output Encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is to prevent arbitrary JavaScript remote code execution within the browser, or if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user supplied data properly to prevent the execution of user supplied input on the browser.

When inserting values into the browser DOM, strongly consider using .value/.innerText/.textContent rather than .innerHTML updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable, and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless completely read only public information, the use of TLS should be mandated, particularly where credentials, updates, deletions and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Erlend Oftedal - erlend.oftedal@owasp.org 
Andrew van der Stock - vanderaj@owasp.org 

[[Category:Cheatsheets]]

REST Security Cheat Sheet

2013-08-22T22:24:48Z

Eoftedal: /* Direct object references */

= Introduction =

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] or REpresentational State Transfer is a means of expressing specific entities in a system by URL path elements, REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URL's rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and Session Management =

RESTful web services should use session based authentication, either by establishing a session token via a POST, or using an API key as a POST body argument or as a cookie. Usernames and passwords, session tokens and API keys should not appear in the URL, as this can be captured in web server logs and makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS and API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider just using the session token or API key to maintain client state in a server side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt and change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry, whereas for the librarian, both of these are valid uses.

== Whitelist Allowable Methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>POST</tt> would update an existing entity, <tt>PUT</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs will work, all others return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure Direct object references ==

It may seem obvious, but if you had a bank account REST web service, you have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly insane. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

Please make sure you understand how to protect against [[Top_10_2010-A4-Insecure_Direct_Object_References|insecure direct object references]] in the OWASP Top 10 2010.

= Input Validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate Incoming Content-Types ==

When POSTing or PUTing new data, the client will specify the a Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type, but always check that the Content-Type header and the content is of the same type. A lack of Content-Type header or an unexpected Content-Type header, should result in the server rejecting the Content with a <tt>406 Not Acceptable</tt> response.

== Validate Response Types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML Input Validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

= Output Encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is to prevent arbitrary JavaScript remote code execution within the browser, or if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user supplied data properly to prevent the execution of user supplied input on the browser.

When inserting values into the browser DOM, strongly consider using .value/.innerText/.textContent rather than .innerHTML updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable, and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless completely read only public information, the use of TLS should be mandated, particularly where credentials, updates, deletions and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Erlend Oftedal - erlend.oftedal@owasp.org 
Andrew van der Stock - vanderaj@owasp.org 

[[Category:Cheatsheets]]

Testing for NoSQL injection

2013-08-19T13:26:53Z

Eoftedal: /* References */ typo

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
 
NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
 
== Description of the Issue ==
 
NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.

There are now over 150 NoSQL databases available[http://nosql-database.org/] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests.

NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call.

Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing.

At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
 
== Black Box testing and example ==
'''Testing for NoSQL injection vulnerabilities in MongoDB:''' 
The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.

The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL.

<code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>

Optionally JavaScript is also evaluated to allow more advanced conditions.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

===Example 1===

If an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query. An example vulnerability is exposed in the following code, if user input is passed directly into the MongoDB query without sanitization.

<code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>

As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error.

<code>' " \ ; { }</code>

With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript.

This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.

<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>

===Example 2===

Even if the input used within queries is completely sanitized or parameterized, there is an alternate path in which one might trigger NoSQL injection. Many NoSQL instances have their own reserved variable names, independent of the application programming language.

For example within MongoDB, the <code>$where</code> syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because <code>$where</code> is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named <code>$where</code>. The PHP MongoDB documentation explicitly warns developers: <pre>Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.</pre>

Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

 
== References ==
'''Whitepapers''' 
Bryan Sullivan from Adobe: "Server-Side JavaScript Injection" - https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

Bryan Sullivan from Adobe: "NoSQL, But Even Less Security" - http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf

Erlend from Bekk Consulting: "[Security] NOSQL-injection" - http://erlend.oftedal.no/blog/?blogid=110

Felipe Aragon from Syhunt: "NoSQL/SSJS Injection" - http://www.syhunt.com/?n=Articles.NoSQLInjection

MongoDB Documentation: "How does MongoDB address SQL or Query injection?" - http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection

PHP Documentation: "MongoCollection::find" - http://php.net/manual/en/mongocollection.find.php

OWASP SafeNuGet

2013-06-23T20:50:34Z

Eoftedal:

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. SafeNuGet can currently be used to scan .NET applications to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

OWASP SafeNuGet is an MSBuild task which will warn developers if they are using NuGet packages with known vulnerabilities.

More information about SafeNuGet can be found on the [https://github.com/owasp/SafeNuGet Github SafeNuGet site].

For a similar tool for java see [[OWASP_Dependency_Check]]

=Project About=
{{:Projects/OWASP_SafeNuGet}}

[[Category:OWASP Project]]

OWASP SafeNuGet

2013-06-23T20:48:31Z

Eoftedal:

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. SafeNuGet can currently be used to scan .NET applications to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

OWASP SafeNuGet is an MSBuild task which will warn developers if they are using NuGet packages with known vulnerabilities.

More information about SafeNuGet can be found on the [https://github.com/owasp/SafeNuGet Github SafeNuGet site].

=Project About=
{{:Projects/OWASP_SafeNuGet}}

[[Category:OWASP Project]]

OWASP SafeNuGet

2013-06-23T20:48:15Z

Eoftedal:

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. SafeNuGet can currently be used to scan .NET applications to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

OWASP SafeNuGet is an MSBuild task which will warn developers if they are using NuGet packages with known vulnerabilities.

More information about dependency-check can be found on the [https://github.com/owasp/SafeNuGet Github SafeNuGet site].

=Project About=
{{:Projects/OWASP_SafeNuGet}}

[[Category:OWASP Project]]

Projects/OWASP SafeNuGet/Releases/Current

2013-06-23T19:15:57Z

Eoftedal:

The latest release is found here: [http://nuget.org/packages/SafeNuGet/ http://nuget.org/packages/SafeNuGet/]

The code is here: [http://github.com/OWASP/SafeNuGet/ http://github.com/OWASP/SafeNuGet/]

Projects/OWASP SafeNuGet/Releases/Current

2013-06-23T19:14:54Z

Eoftedal: Created page with "The latest release is found here: [http://nuget.org/packages/SafeNuGet/ http://nuget.org/packages/SafeNuGet/]"

The latest release is found here: [http://nuget.org/packages/SafeNuGet/ http://nuget.org/packages/SafeNuGet/]

Projects/OWASP SafeNuGet

2013-06-23T18:56:01Z

Eoftedal: Created page with "{{Template:Project About | project_name =OWASP SafeNuGet | project_home_page =OWASP_SafeNuGet | project_description =OWASP SafeNuGet is an MsBuild task to warn about the use o..."

{{Template:Project About
| project_name =OWASP SafeNuGet
| project_home_page =OWASP_SafeNuGet
| project_description =OWASP SafeNuGet is an MsBuild task to warn about the use of NuGet libraries with known vulnerabilities.
| project_license =GNU GPL v3 License
| leader_name1 =Erlend Oftedal
| leader_email1 =erlend.oftedal@owasp.org
| mailing_list_name = N/A
| project_road_map = https://www.owasp.org/index.php/Projects/OWASP_SafeNuGet/Roadmap

| links_url1 = https://github.com/OWASP/SafeNuGet
| links_name1 = https://github.com/OWASP/SafeNuGet
}}

OWASP SafeNuGet

2013-06-23T17:26:01Z

Eoftedal: initial version

The OWASP Top 10 2013 contains a new entry: [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities A9 - Using Components with Known Vulnerabilities]. Dependency-check can currently be used to scan Java applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf The Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [http://web.nvd.nist.gov/view/vuln/search National Vulnerability Database]).

OWASP SafeNuGet is an MSBuild task which will warn developers if they are using NuGet packages with known vulnerabilities.

More information about dependency-check can be found on the [https://github.com/owasp/SafeNuGet Github SafeNuGet site].

=Project About=
{{:Projects/OWASP_SafeNuGet}}

[[Category:OWASP Project]]

Category:OWASP Project

2013-06-23T17:23:08Z

Eoftedal: Adding OWASP SafeNuGet

__NOTOC__
{|
|-
! width="700" align="center" | 
! width="500" align="center" | 
|-
| align="center" | [[Image:NEW-PROJECTS-BANNER.jpg|950px| link=https://www.owasp.org/index.php/Category:OWASP_Project]]
| align="center" |

|}

= Welcome =
{| style="width: 100%;"
|-
| style="width: 100%; color: rgb(0, 0, 0);" |
{| style="border: 0px solid ; background: transparent none repeat scroll 0% 0%; width: 100%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;"
|-
| style="width: 95%; color: rgb(0, 0, 0);" |


=== Welcome to the OWASP Global Projects Page ===

An OWASP project is a collection of related tasks that have a defined roadmap and team members. OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team. OWASP currently has over 148 active projects, and new project applications are submitted every week.

This is one of the most popular divisions of OWASP as it gives members an opportunity to freely test theories and ideas with the professional advice and support of the OWASP community. Every project has an associated mail list. You can view all the lists, examine their archives, and subscribe to any project by visiting the [http://lists.owasp.org/mailman/listinfo OWASP Project Mailing Lists] page. A summary of recent project announcements is available on the [[OWASP Updates]] page.

'''[https://www.owasp.org/images/6/6a/OWASP_Projects_Handbook_2013.pdf Download the OWASP Projects Handbook 2013]'''

=== OWASP Project Inventory ===

All OWASP tools, document, and code library projects are organized into the following categories:

* '''[https://www.owasp.org/index.php/OWASP_Project_Inventory#Incubator_Projects Incubator Projects:]''' OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway.

* '''[https://www.owasp.org/index.php/OWASP_Project_Inventory#Labs_Projects Lab Projects:]''' OWASP Labs projects represent projects that have produced an OWASP reviewed deliverable of value.

* '''[https://www.owasp.org/index.php/OWASP_Project_Inventory#Flagship_Projects Flagship Projects:]''' The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole.

=== Who Should Start an OWASP Project? ===

*Application Developers.
*Software Architects.
* Information Security Authors.
*Those who would like the support of a world wide professional community to develop or test an idea.
*Anyone wishing to take advantage of the professional body of knowledge OWASP has to offer.

=== Contact Us===

If you have any questions, please do not hesitate to contact the [http://owasp4.owasp.org/contactus.html OWASP Projects Manager, Samantha Groves] by using the form provided here. Please allow five working days for your question or comment to be answered. This is due to the large amount of queries the foundation staff receive every day. We thank you for your patience.

=== Social Media ===

We recommend using the links below to find our official OWASP social media channels. These are a great way to keep in touch with the different initiatives going on at OWASP throughout the world. They are all updated regularly by chapter leaders, project leaders, the OWASP Board Members, and our OWASP Staff. If you have any questions or concerns about any of these accounts, please drop us a line using our [https://docs.google.com/a/owasp.org/spreadsheet/viewform?formkey=dGR5QXFWYThiOHZNSldCdkFIMW9kNXc6MQ "Contact Us"] form found above.

[[Image:Blogger-32x32.png|32px|link=http://owasp.blogspot.co.uk/]] [[Image:Twitter-32x32.png|32px|link=https://twitter.com/OWASP]] [[Image:Facebook-32x32.png|32px|link=https://www.facebook.com/groups/172892372831444/]] [[Image:Linkedin-32x32.png|32px|link=http://www.linkedin.com/groups/Global-OWASP-Foundation-36874]] [[Image:Google-32x32.png|32px|link=https://plus.google.com/u/0/communities/105181517914716500346?cfem=1]] [[Image:Ning-32x32.png|32px|link=http://myowasp.ning.com/]]





 

|}



| style="border: 3px solid rgb(204, 204, 204); vertical-align: top; width: 95%; font-size: 95%; color: rgb(0, 0, 0);" | 

                                                                                                                              [[Image:Projects_Front_Page_Graphic3.jpg|center|300px| link=https://www.owasp.org/index.php/OWASP_Mobile_Security_Project]]

[[Image:AppSec USA.jpg|center|300px| link=http://www.appsecusa.org/]]

[[Image:Projects_Banner_3.jpg|center|300px| link=http://owasp.force.com/volunteers/GW_Volunteers__VolunteersJobListing]]

[[Image:Projects_Front_Page_Donation.jpg|center|300px| link=http://www.regonline.com/Register/Checkin.aspx?EventID=1044369]]

{|

| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}

| style="width: 110px; font-size: 95%; color: rgb(0, 0, 0);" |
|}


= Starting a New Project =

== So you want to start a project... ==

Starting an OWASP Project is easy. You don't have to be an application security expert. You just have to have the drive and desire to make a contribution to the application security community.

Here are some of the guidelines for running a successful OWASP project:

* The best OWASP projects are strategic - they make it easier to produce secure applications by filling a gap in the application security knowledge-base or technology support.

* You ''can'' run a single person project, but it's usually best to get the community involved. You should be prepared to support a mailing list, build a team, speak at conferences, and promote your project.

* You can contribute existing documents or tools to OWASP! Assuming you have the intellectual property rights to a work, you can open it to the world as an OWASP Project. Please coordinate this with OWASP by contacting owasp(at)owasp.org.

* Available Grants to consider if you need funding - [https://www.owasp.org/index.php/Grants Click Here]

* You should promote your project through the OWASP channels as well as by outside means. Get people to blog about it!

== Creating a new project ==

[http://sl.owasp.org/new-project Here's the simple process for starting a new OWASP Project].
* Check out the '''[[Guidelines for OWASP Projects]]'''.

 
* Get the following information together:

A - PROJECT
# Project Name,
# Project purpose / overview,
# Project Roadmap,
# Project links (if any) to external sites,
# [http://www.owasp.org/index.php/Guidelines_for_OWASP_Projects#Project_Licensing Project License],
# Project Leader name,
# Project Leader email address,
# Project Leader wiki account - the username (you'll need this to edit the wiki),
# Project Contributor(s) (if any) - name email and wiki account (if any),
# Project Main Links (if any).
 

==OWASP Recommended Licenses==

{{Recommended_Licenses}}

==Funding your Project==
An OWASP project does not receive any funding for development at project inception; however, a new project does have the opportunity to submit an application to receive funds if they are available for the year. Additionally, project leaders have the option of seeking sponsorship from outside organisations, but project leaders are required to seek funding through their own initiative.

== Project Release ==

*As your project reaches a point that you'd like OWASP to assist in its promotion, the [[Global Projects Committee|OWASP Global Projects Committee]] will need the following to help spread the word about your project:

# [http://globalprojectscommittee.wordpress.com/2009/07/27/what-is-the-3x-slide-presentation-thing/ Conference style presentation that describes the tool/document in at least 3 slides],
# [http://globalprojectscommittee.wordpress.com/2009/07/21/what-is-this-project-flyerpamphlet-thing/ Project Flyer/Pamphlet (PDF file)],
 
* If possible, get also the following information together:

B – FIRST RELEASE
# Release Name,
# Release Description,
# Release Downloadable file link
# Release Leader,
# Release Contributor(s),
# Release Reviewer,
# Release Sponsor(s) (if any),
# Release Notes
# Release Main Links (if any),

==Project Process Forms==
These forms were created to help project leaders, and those interested in a going through a process in the OWASP projects infrastructure. They facilitate the management of each query based on the specific task an applicant will need help with. The forms are described below, and they are linked with their designated online application form.

* [http://www.tfaforms.com/264422 Project Transition Application]:The OWASP project transition form gives current project leaders an easy way of handing over project administration information to individuals wishing to take over a project.

* [http://www.tfaforms.com/264413 Project Review Application]:This form is for current project leaders to request a review of their project based on OWASP graduation criteria. The aim is to designate an OWASP volunteer to review these projects within 3 months time.

* [http://www.tfaforms.com/264418 Project Donation Application]:This form is for projects outside of the OWASP project infrastructure. Project Leaders for these open source projects can choose to partner or give their project to OWASP directly through this form.

* [http://www.tfaforms.com/264428 Project Adoption Request]:This form is used when someone is interested in adopting an archived project.

* [http://www.tfaforms.com/264426 Project Abandonment Request]:The OWASP project abandonment form gives current project leaders an easy way of letting the OWASP Foundation know that they wish to resign their project leader duties. This form should be used when no replacement project leader exists to take over these duties.

* [http://www.tfaforms.com/264392 Incubator Project Graduation Application]:This application form is for Incubator Projects to apply for Labs Project status.

= Project Assessments =

==OWASP Project Lifecycle==
The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality. The lifecycle stage allows consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classified as prototypes in their current state. The greater the maturity of the project, the greater the level of responsibility for the project leader. These responsibilities are not trivial as OWASP provides incentives and benefits (Section 7) for projects who take on these added responsibilities.

'''The OWASP Project Lifecycle is broken down into the following stages:'''

'''Incubator Projects:''' OWASP Incubator projects represent the experimental playground where projects are still being designed, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity; moreover, the label allows project leaders to leverage the OWASP name while their project is still maturing. OWASP Incubator projects are given a place on the OWASP Projects Portal to leverage the organizations' infrastructure, and establish their presence and project history.

'''Labs Projects:''' OWASP Labs projects represent projects that have produced a deliverable of significant value. Leaders of OWASP Labs projects are expected to stand behind the quality of their projects as these projects have matured to the point where they are accepted by a significant portion of the OWASP community. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are ready for mainstream usage. OWASP Labs Projects are meant to be the collection of established projects that have gained community support and acclaim by undergoing the project review process.

'''Flagship Projects:''' The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. Eligible projects are selected from the OWASP Labs project pool. This selection process generally ensures that there is only one project of each type covering any particular security space. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining. The core mission of OWASP is to make application security visible and so as an organization, OWASP has a vested interest in the success of its Flagship projects. Since Flagship projects have such high visibility, these projects are expected to uphold the most stringent requirements of all OWASP Projects.

== OWASP Project Stage Benefits==
This section outlines the benefits of starting an OWASP project, and the benefits of being at each different stage in the projects lifecycle. In my short time here at OWASP as the PM, I have had several potential project leaders ask me what the benefits are of starting their project with OWASP. Below is my proposal for each Stage’s benefits.

'''Incubator'''
* Financial Donation Management Assistance
* Project Review Support
* WASPY Awards Nominations
* OWASP OSS and OPT Participation
* Opportunity to submit proposal: $500 for Development.
* Community Engagement and Support
* Recognition and visibility of being associated with the OWASP Brand.

'''Labs'''
* All benefits given to Incubator Projects
* Technical Writing Support
* Graphic Design Support
* Project Promotion Support
* OWASP OSS and OPT: Preference

'''Flagship'''
* All benefits given to Incubator & Labs Projects
* Grant finding and proposal writing help
* Yearly marketing plan development
* OWASP OSS and OPT participation preference

For more detailed information on OWASP Project Stage Benefits, please see the 2013 Project Handbook.

== OWASP Project Graduation==
The Project Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs. In order to be considered for OWASP Labs, an Incubator project must have submitted an OWASP reviewed deliverable, and obtained at least two (2) positive responses for each of the core criteria project health questions.

The review centers around the following core questions. Each core question has three (3) specific questions made up of binary queries. A project must receive at least two (2) positive responses from each reviewer in two of the binary questions, to warrant a postive response for the core question. Each core question must receive a positive response from both project reviewers to pass the Project Health Assessment for Incubator Projects.

* [https://docs.google.com/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE Project Graduation Criteria Checklist]

==OWASP Project Health Assessment==
The Project Health Assessment is an optional process undertaken at the request of a project leader when he/she applies for Project Graduation The purpose of this assessment is to determine whether a project meets the minimum criteria of an OWASP Project outlined in the [https://docs.google.com/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE Project Health Assessment Criteria Document]. If a project passes the assessment, it then becomes eligible to graduate into the OWASP Labs Project stage. In order to be considered for OWASP Labs, an Incubator project must have submitted an OWASP reviewed deliverable, and obtained at least two (2) positive responses for each of the core criteria project health questions.

==OWASP Project Deliverable/Release Assessment==
The Project Deliverable/Release Review is an optional process undertaken at the request of a project leader using the Project Deliverable Review Form. The purpose of this process is to review a project’s progress, and to make sure the project is heading in the right direction based on the roadmap they provided at project inception.

Reviews must be performed by two (2) OWASP Chapter or Project Leaders, and their review must answer affirmatively to at least the first two (2) core Project Deliverable/Release Review questions. A project must pass the OWASP Project Deliverable/Release Assessment in order to graduate into the OWASP Labs Project stage.

* [https://docs.google.com/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE Project Deliverable/Release Assessment Criteria Checklist]

= Project Inventory =


==Flagship Projects==

The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining.

'''Code'''
* [https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project OWASP AntiSamy Project]
* [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP Enterprise Security API]
* [https://www.owasp.org/index.php/Projects/OWASP_ModSecurity_Core_Rule_Set_Project OWASP ModSecurity Core Rule Set Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project OWASP CSRFGuard Project]

'''Tools'''
* [https://www.owasp.org/index.php?title=OWASP_Web_Testing_Environment_Project OWASP Web Testing Environment Project]
* [https://www.owasp.org/index.php/Webgoat OWASP WebGoat Project]
* [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP Zed Attack Proxy]

'''Documentation'''
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard Project]
* [https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project OWASP Code Review Guide Project]
* [https://www.owasp.org/index.php/OWASP_Codes_of_Conduct OWASP Codes of Conduct]
* [https://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide Project]
* [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP Secure Coding Practices - Quick Reference Guide]
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model OWASP Software Assurance Maturity Model (SAMM)]
* [https://www.owasp.org/index.php/OWASP_Testing_Project OWASP Testing Guide Project]
* [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Project]

==Labs Projects==

OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.

'''Tools'''
* [https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project OWASP Broken Web Applications Project]
* [https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRFTester Project]
* [https://www.owasp.org/index.php/Category:OWASP_EnDe OWASP EnDe Project]
* [https://www.owasp.org/index.php/OWASP_Fiddler_Addons_for_Security_Testing_Project OWASP Fiddler Addons for Security Testing Project]
* [https://www.owasp.org/index.php/OWASP_Forward_Exploit_Tool_Project OWASP Forward Exploit Tool Project]
* [https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project OWASP Hackademic Challenges Project]
* [https://www.owasp.org/index.php/OWASP_Hatkit_Datafiddler_Project OWASP Hatkit Datafiddler Project]
* [https://www.owasp.org/index.php/OWASP_Hatkit_Proxy_Project OWASP Hatkit Proxy Project]
* [https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool OWASP HTTP POST Tool]
* [https://www.owasp.org/index.php/OWASP_Java_XML_Templates_Project OWASP Java XML Templates Project]
* [https://www.owasp.org/index.php/OWASP_JavaScript_Sandboxes OWASP JavaScript Sandboxes Project]
* [https://www.owasp.org/index.php/Category:OWASP_Joomla_Vulnerability_Scanner_Project OWASP Joomla Vulnerability Scanner Project]
* [https://www.owasp.org/index.php/OWASP_LAPSE_Project OWASP LAPSE Project]
* [https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework OWASP Mantra Security Framework]
* [https://www.owasp.org/index.php/Category:OWASP_Mutillidae OWASP Mutillidae Project]
* [https://www.owasp.org/index.php/OWASP_O2_Platform OWASP O2 Platform]
* [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]
* [https://www.owasp.org/index.php/Scrubbr OWASP Scrubbr]
* [http://owasp.com/index.php/Category:OWASP_Security_Assurance_Testing_of_Virtual_Worlds_Project OWASP Security Assurance Testing of Virtual Worlds Project]
* [https://www.owasp.org/index.php/Project_Information:template_Vicnum_Project OWASP Vicnum Project]
* [https://www.owasp.org/index.php/Category:OWASP_Wapiti_Project OWASP Wapiti Project]
* [https://www.owasp.org/index.php/OWASP_Web_Browser_Testing_System_Project OWASP Web Browser Testing System Project]
* [https://www.owasp.org/index.php/Webscarab OWASP WebScarab Project]
* [https://www.owasp.org/index.php/Project_Information:template_Webslayer_Project OWASP Webslayer Project]
* [https://www.owasp.org/index.php/Project_Information:template_WSFuzzer_Project OWASP WSFuzzer Project]
* [https://www.owasp.org/index.php/Project_Information:template_Yasca_Project OWASP Yasca Project]

'''Documentation'''
* [https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series OWASP AppSec Tutorial Series]
* [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor Project]
* [https://www.owasp.org/index.php/Category:OWASP_Cloud_‐_10_Project OWASP Cloud ‐ 10 Project]
* [https://www.owasp.org/index.php/Category:OWASP_CTF_Project OWASP CTF Project]
* [https://www.owasp.org/index.php/Category:OWASP_Fuzzing_Code_Database OWASP Fuzzing Code Database]
* [https://www.owasp.org/index.php/Category:OWASP_Legal_Project OWASP Legal Project]
* [https://www.owasp.org/index.php/OWASP_Podcast OWASP Podcast Project]
* [https://www.owasp.org/index.php/Virtual_Patching_Best_Practices Virtual Patching Best Practices]

<div id="sammysam"></div>
==Incubator Projects==

OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.

'''Code'''
* [https://www.owasp.org/index.php/OWASP_Secure_the_Flag_Competition_Project OWASP Secure the Flag Project]
* [https://www.owasp.org/index.php/Opa OWASP OPA]
* [https://www.owasp.org/index.php/OWASP_Alchemist_Project OWASP Alchemist Project]
* [https://www.owasp.org/index.php/OWASP_ESOP_Framework OWASP ESOP Framework]
* [https://www.owasp.org/index.php/OWASP_Java_Encoder_Project OWASP Java Encoder Project]
* [https://www.owasp.org/index.php/OWASP_Passfault OWASP Passfault]
* [https://www.owasp.org/index.php/OWASP_OctoMS OWASP OctoMS]
* [https://www.owasp.org/index.php/OWASP_Java_Uncertain_Form_Submit_Prevention OWASP Java Uncertain Form Submit Prevention]
* [https://www.owasp.org/index.php/OWASP_Ecuador OWASP Ecuador]
* [https://www.owasp.org/index.php/OWASP_AW00T OWASP AW00t]
* [https://www.owasp.org/index.php/OWASP_ONYX OWASP ONYX]
* [https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer]
* [https://www.owasp.org/index.php/OWASP_Security_Research_and_Development_Framework OWASP Security Research and Development Framework]
* [https://www.owasp.org/index.php/OWASP_1-Liner OWASP 1-Liner]
* [https://www.owasp.org/index.php/OWASP_Focus OWASP Focus]
* [https://www.owasp.org/index.php/OWASP_PHPRBAC_Project OWASP PHPRBAC Project]
* [https://www.owasp.org/index.php/OWASP_EJSF_Project OWASP EJSF Project]
* [https://www.owasp.org/index.php/OWASP_Barbarus OWASP Barbarus]
* [https://www.owasp.org/index.php/OWASP_iMAS_iOS_Mobile_Application_Security_Project OWASP iMAS - iOS Mobile Application Security Project]
* [https://www.owasp.org/index.php/OWASP_RBAC_Project OWASP RBAC Project]
* [https://www.owasp.org/index.php/OWASP_PHP_Security_Project OWASP PHP Security Project]
* [https://www.owasp.org/index.php/OWASP_Simple_Host_Base_Incidence_Detection_System_Project OWASP Simple Host Base Incidence Detection System Project]

'''Tools'''
* [https://www.owasp.org/index.php/OWASP_WhatTheFuzz_Project#tab=Project_About OWASP WhatTheFuzz Project]
* [https://www.owasp.org/index.php/OWASP_Security_Tools_for_Developers_Project OWASP Security Tools for Developers Project]
* [https://www.owasp.org/index.php/OWASP_SIMBA_Project OWASP SIMBA Project]
* [https://www.owasp.org/index.php/OWASP_VFW_Project OWASP VFW Project]
* [https://www.owasp.org/index.php/OWASP_OVAL_Content_Project OWASP OVAL Content Project]
* [https://www.owasp.org/index.php/OWASP_WAF_Project OWASP WAF Project]
* [https://www.owasp.org/index.php/OWASP_NAXSI_Project OWASP NAXSI Project]
* [https://www.owasp.org/index.php/OWASP_Passw3rd_Project OWASP Passw3rd Project]
* [https://www.owasp.org/index.php/OWASP_File_Hash_Repository OWASP File Hash Repository]
* [https://www.owasp.org/index.php/Category:OWASP_WebGoat.NET OWASP WebGoat.NET]
* [https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool OWASP AJAX Crawling Tool]
* [https://www.owasp.org/index.php/OWASP_OWTF OWASP OWTF]
* [https://www.owasp.org/index.php/OWASP_Path_Traverser OWASP Path Traverser]
* [https://www.owasp.org/index.php/OWASP_Watiqay OWASP Watiqay]
* [https://www.owasp.org/index.php/OWASP_Security_Shepherd OWASP Security Shepherd]
* [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework OWASP Xenotix XSS Exploit Framework]
* [https://www.owasp.org/index.php/OWASP_Mantra_OS OWASP Mantra OS]
* [https://www.owasp.org/index.php/OWASP_XSSER OWASP XSSER]
* [https://www.owasp.org/index.php/OWASP_Academy_Portal_Project OWASP Academy Portal Project]
* [https://www.owasp.org/index.php/OWASP_ASIDE_Project OWASP ASIDE Project]
* [https://www.owasp.org/index.php/OWASP_Browser_Security_ACID_Tests_Project OWASP Browser Security ACID Test Project]
* [https://www.owasp.org/index.php/OWASP_iGoat_Project OWASP iGoat Project]
* [https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer OWASP Java HTML Sanitizer Project]
* [https://www.owasp.org/index.php/Category:OWASP_Proxy OWASP Proxy Project]
* [https://www.owasp.org/index.php/OWASP_SamuraiWTF_Project OWASP SamuraiWTF]
* [https://www.owasp.org/index.php/O-Saft O-Saft]
* [https://www.owasp.org/index.php/OWASP_Crowdtesting OWASP Crowdtesting]
* [https://www.owasp.org/index.php/OWASP_OpenStack_Security_Project OWASP OpenStack Security Project]
* [https://www.owasp.org/index.php/OWASP_Desktop_Goat_and_Top_5_Project OWASP Desktop Goat and Top 5 Project]
* [https://www.owasp.org/index.php/OWASP_Bricks OWASP Bricks]
* [https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check]
* [https://www.owasp.org/index.php/OWASP_SafeNuGet OWASP SafeNuGet]
* [https://www.owasp.org/index.php/OWASP_Hive_Project OWASP Hive Project]
* [https://www.owasp.org/index.php/OWASP_Droid_Fusion OWASP Droid Fusion]
* [https://www.owasp.org/index.php/OWASP_iSABEL_Proxy_Server OWASP iSABEL Proxy Server]
* [https://www.owasp.org/index.php/OWASP_Rails_Goat_Project OWASP Rails Goat Project]
* [https://www.owasp.org/index.php/OWASP_Bywaf_Project OWASP Bywaf Project]
* [https://www.owasp.org/index.php/OWASP_S.T.I.N.G_Project OWASP S.T.I.N.G Project]
* [https://www.owasp.org/index.php/OWASP_Application_Fuzzing_Framework_Project OWASP Application Fuzzing Framework Project]
* [https://www.owasp.org/index.php/OWASP_VaultDB_Project OWASP VaultDB Project]
* [https://www.owasp.org/index.php/OWASP_WS_Amplification_DoS_Project OWASP WS-Amplification DoS Project]
* [https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project OWASP Mutillidae 2 Project]
* [https://www.owasp.org/index.php/OWASP_Skanda_SSRF_Exploitation_Framework OWASP Skanda - SSRF Exploitation Framework]
* [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project OWASP SeraphimDroid Project]

'''Documentation'''
* [https://www.owasp.org/index.php/OWASP_Data_Exchange_Format_Project OWASP Data Exchange Format Project]
* [https://www.owasp.org/index.php/Cheat_Sheets OWASP Cheat Sheets Project]
* [https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Proactive Controls]
* [https://www.owasp.org/index.php/OWASP_Java_J2EE_Secure_Development_Curriculum OWASP Java/J2EE Secure Development Curriculum]
* [https://www.owasp.org/index.php/OWASP_Crossword_of_the_Month OWASP Crossword of the Month]
* [https://www.owasp.org/index.php/OWASP_Secure_Password_Project OWASP Secure Password Project]
* [https://www.owasp.org/index.php/OWASP_Security_Baseline_Project OWASP Security Baseline Project]
* [https://www.owasp.org/index.php/OWASP_Software_Security_Assurance_Process OWASP Software Security Assurance Process]
* [https://www.owasp.org/index.php/OWASP_Threat_Modelling_Project OWASP Threat Modeling Project]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Accessibility_Project#tab=Project_About OWASP Web Application Security Accessibility Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project OWASP Application Security Requirements Project]
* [https://www.owasp.org/index.php/OWASP_Common_Numbering_Project OWASP Common Numbering Project]
* [https://www.owasp.org/index.php/Category:OWASP_Favicon_Database_Project OWASP Favicon Database Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Assessment_Standards_Project OWASP Application Security Assessment Standards Project]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Program_for_Managers OWASP Application Security Program for Managers]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Skills_Assessment OWASP Application Security Skills Assessment]
* [https://www.owasp.org/index.php/OWASP_Browser_Security_Project OWASP Browser Security Project]
* [https://www.owasp.org/index.php/Category:OWASP_CBT_Project OWASP Computer Based Training Project (OWASP CBT Project)]
* [https://www.owasp.org/index.php/OWASP_Enterprise_Application_Security_Project OWASP Enterprise Application Security Project]
* [https://www.owasp.org/index.php/OWASP_Exams_Project OWASP Exams Project]
* [https://www.owasp.org/index.php/Projects/OWASP_GoatDroid_Project OWASP GoatDroid Project]
* [https://www.owasp.org/index.php/OWASP_Myth_Breakers_Project OWASP Myth Breakers Project]
* [http://owasp.com/index.php/OWASP_Project_Partnership_Model OWASP Project Partnership Model]
* [https://www.owasp.org/index.php/OWASP_RFP-Criteria OWASP Request For Proposal]
* [https://www.owasp.org/index.php/OWASP_University_Challenge OWASP University Challenge]
* [https://www.owasp.org/index.php/OWASP_Hacking_Lab OWASP Hacking-Lab]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Awareness_Top_10_E-learning_Project OWASP Application Security Awareness Top 10 E-learning Project]
* [https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities OWASP Periodic Table of Vulnerabilities]
* [https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project WASC/OWASP Web Application Firewall Evaluation Criteria (WAFEC)]
* [https://www.owasp.org/index.php/ESAPI_Swingset OWASP ESAPI Swingset Project]
* [https://www.owasp.org/index.php/OWASP_Press OWASP Press]
* [https://www.owasp.org/index.php/OWASP_CISO_Survey OWASP CISO Survey]
* [https://www.owasp.org/index.php/OWASP_Application_Security_Guide_For_CISOs_Project OWASP Application Security Guide For CISOs]
* [https://www.owasp.org/index.php/OWASP_Embedded_Application_Security OWASP Embedded Application Security]
* [https://www.owasp.org/index.php/OWASP_Scada_Security_Project OWASP Scada Security Project]
* [https://www.owasp.org/index.php/OWASP_Cornucopia OWASP Cornucopia]
* [https://www.owasp.org/index.php/OWASP_Secure_Application_Design_Project OWASP Secure Application Design Project]
* [https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 Fuer Entwickler Project]
* [https://www.owasp.org/index.php/OWASP_Good_Component_Practices_Project OWASP Good Component Practices Project]
* [https://www.owasp.org/index.php/OWASP_Web_Application_Security_Quick_Reference_Guide_Project OWASP Web Application Security Quick Reference Guide Project]
* [https://www.owasp.org/index.php/OWASP_Security_JDIs_Project OWASP Security JDIs Project]
* [https://www.owasp.org/index.php/OWASP_Windows_Binary_Executable_Files_Security_Checks_Project OWASP Windows Binary Executable Files Security Checks Project]
* [https://www.owasp.org/index.php/OWASP_Wordpress_Security_Checklist_Project OWASP Wordpress Security Checklist Project]
* [https://www.owasp.org/index.php/OWASP_Supporting_Legacy_Web_Applications_in_the_Current_Environment_Project OWASP Supporting Legacy Web Applications in the Current Environment Project]

==Inactive Projects==

'''Archived Projects'''

OWASP Archived Projects are inactive Labs projects. If you are interested in pursuing any of the projects below, please contact us and let us know of your interest.

* [https://www.owasp.org/index.php/Category:OWASP_Access_Control_Rules_Tester_Project OWASP Access Control Rules Tester Project]
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Metrics_Project OWASP Application Security Metrics Project]
* [https://www.owasp.org/index.php/Category:OWASP_AppSec_FAQ_Project OWASP AppSec FAQ Project]
* [https://www.owasp.org/index.php/Asdr OWASP ASDR Project]
* [https://www.owasp.org/index.php/Category:OWASP_Backend_Security_Project OWASP Backend Security Project]
* [https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls OWASP Best Practices: Use of Web Application Firewalls]
* [https://www.owasp.org/index.php/Category:OWASP_CAL9000_Project OWASP CAL9000 Project]
* [https://www.owasp.org/index.php/Category:OWASP_CLASP_Project OWASP CLASP Project]
* [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler OWASP CodeCrawler Project]
* [https://www.owasp.org/index.php/Category:OWASP_Content_Validation_using_Java_Annotations_Project OWASP Content Validation using Java Annotations Project]
* [https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project OWASP DirBuster Project]
* [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project OWASP Encoding Project]
* [https://www.owasp.org/index.php/Category:OWASP_Google_Hacking_Project OWASP Google Hacking Project]
* [https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project OWASP Insecure Web App Project]
* [https://www.owasp.org/index.php/Category:OWASP_Interceptor_Project OWASP Interceptor Project]
* [https://www.owasp.org/index.php/Category:OWASP_JSP_Testing_Tool_Project OWASP JSP Testing Tool Project]
* [https://www.owasp.org/index.php/Category:OWASP_LiveCD_Education_Project OWASP LiveCD Education Project]
* [https://www.owasp.org/index.php/Category:OWASP_Logging_Project OWASP Logging Guide]
* [https://www.owasp.org/index.php/Category:OWASP_NetBouncer_Project OWASP NetBouncer Project]
* [https://www.owasp.org/index.php/Category:OWASP_OpenPGP_Extensions_for_HTTP_-_Enigform_and_mod_openpgp OWASP OpenPGP Extensions for HTTP - Enigform and mod_openpgp Project]
* [https://www.owasp.org/index.php/Category:OWASP_OpenSign_Server_Project OWASP OpenSign Server Project]
* [https://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project OWASP Pantera Web Assessment Studio Project]
* [https://www.owasp.org/index.php/Category:OWASP_PHP_Project OWASP PHP Project]
* [https://www.owasp.org/index.php/ORG_%28OWASP_Report_Generator%29 OWASP Report Generator]
* [https://www.owasp.org/index.php/Category:OWASP_Ruby_on_Rails_Security_Guide_V2 OWASP Ruby on Rails Security Guide V2]
* [https://www.owasp.org/index.php/Category:OWASP_SASAP_Project OWASP Scholastic Application Security Assessment Project]
* [https://www.owasp.org/index.php/Category:OWASP_Security_Analysis_of_Core_J2EE_Design_Patterns_Project OWASP Security Analysis of Core J2EE Design Patterns Project]
* [https://www.owasp.org/index.php/Category:OWASP_Security_Spending_Benchmarks OWASP Security Spending Benchmarks Project]
* [https://www.owasp.org/index.php/OWASP_SiteGenerator OWASP Site Generator Project]
* [https://www.owasp.org/index.php/Category:OWASP_Skavenger_Project OWASP Skavenger Project]
* [https://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project OWASP Source Code Flaws Top 10 Project]
* [https://www.owasp.org/index.php/Category:OWASP_Sprajax_Project OWASP Sprajax Project]
* [https://www.owasp.org/index.php/Category:OWASP_Sqlibench_Project OWASP Sqlibench Project]
* [https://www.owasp.org/index.php/Category:OWASP_SQLiX_Project OWASP sqliX Project]
* [https://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project]
* [https://www.owasp.org/index.php/Category:OWASP_Teachable_Static_Analysis_Workbench_Project OWASP Teachable Static Analysis Workbench Project]
* [https://www.owasp.org/index.php/OWASP_Tiger OWASP Tiger]
* [https://www.owasp.org/index.php/Category:OWASP_Tools_Project OWASP Tools Project]
* [https://www.owasp.org/index.php/Projects/OWASP_Uniform_Reporting_Guidelines OWASP Uniform Reporting Guidelines]
* [https://www.owasp.org/index.php/Category:OWASP_WeBekci_Project OWASP Webekci Project]
* [https://www.owasp.org/index.php/JBroFuzz JBroFuzz]
* [https://owasp.org/index.php/Category:OWASP_SWAAT_Project OWASP SWAAT Project]
* [https://www.owasp.org/index.php/OWASP_Secure_Web_Application_Framework_Manifesto OWASP Secure Web Application Framework Manifesto]

= Marketing Materials =


==Philosophy==

OWASP stands for informed security decisions based on a solid, comprehensive understanding of the business risk associated with an application. OWASP's philosophy is that achieving security involves all parts of an organization, including people, process, and technology. We support the use of our brand consistent with this philosophy. However, we cannot allow the use of our brand when it implies something inconsistent with OWASP's comprehensive and balanced approach to application security. Therefore, we have defined these brand usage rules to clarify appropriate and inappropriate uses of the OWASP brand, including our name, domain, logos, project names, and other trademarks.

==Brand Usage Rules==

The following rules make reference to all OWASP marketing and graphic materials. This refers to any tools, documentation, or other content from OWASP. The rules also make reference to "OWASP Published Standards" which are currently in the process of being developed and released. Currently there are no OWASP Published Standards.

# The OWASP Brand may be used to direct people to the OWASP website for information about application security.
# The OWASP Brand may be used in commentary about the materials found on the OWASP website.
# The OWASP Brand may be used by OWASP Members in good standing to promote a person or company's involvement in OWASP.
# The OWASP Brand may be used in association with an application security assessment only if a complete and detailed methodology, sufficient to reproduce the results, is disclosed.
# The OWASP Brand must not be used in a manner that suggests that The OWASP Foundation supports, advocates, or recommends any particular product or technology.
# The OWASP Brand must not be used in a manner that suggests that a product or technology is compliant with any OWASP Materials other than an OWASP Published Standard.
# The OWASP Brand must not be used in a manner that suggests that a product or technology can enable compliance with any OWASP Materials other than an OWASP Published Standard.
# The OWASP Brand must not be used in any materials that could mislead readers by narrowly interpreting a broad application security category. For example, a vendor product that can find or protect against forced browsing must not claim that they address all of the access control category.
# The OWASP Brand may be used by special arrangement with The OWASP Foundation.

==Social Media==
[[Image:Blogger-32x32.png|32px|link=http://owasp.blogspot.co.uk/]] [[Image:Twitter-32x32.png|32px|link=https://twitter.com/OWASP]] [[Image:Facebook-32x32.png|32px|link=https://www.facebook.com/groups/172892372831444/]] [[Image:Linkedin-32x32.png|32px|link=http://www.linkedin.com/groups/Global-OWASP-Foundation-36874]] [[Image:Google-32x32.png|32px|link=https://plus.google.com/u/0/communities/105181517914716500346?cfem=1]] [[Image:Ning-32x32.png|32px|link=http://myowasp.ning.com/]]

==Resources==
* '''[https://www.owasp.org/images/0/07/OWASP_Image_Toolbox.zip OWASP Logo Toolbox]:''' This includes all of OWASP's logo image files in various formats.
* '''[https://www.owasp.org/images/2/2a/OWASP_BUSINESS_CARD_TEMPLATES.zip OWASP Business Card Templates]:''' This includes the front and back PSD files for the OWASP Business Card.

'''Merchandise Requests'''

*Submit your application using the '''[https://spreadsheets.google.com/a/owasp.org/spreadsheet/viewform?formkey=dF85bGtvdWdrd2JjYldNZ1gxSkJxaEE6MQ OWASP Merchandise Request Form]'''.

'''Ads/Flyers'''

* '''[https://www.owasp.org/images/4/49/OWASP_Brochure_-_Global.pdf OWASP Flyer]'''
* '''[https://www.owasp.org/images/a/ac/OWASP-AD-V3-FINAL.pdf OWASP 2012 Standard Print Ad]'''
* '''[https://www.owasp.org/images/2/2d/OWASP-AD-V3-FINAL-A4.pdf OWASP 2012 A4 Print Ready Ad]'''
* '''[https://www.owasp.org/images/1/1f/OWASP-AD-V3-FINAL-A42.pdf OWASP 2012 A4-2 Print Ready Ad]'''

'''Banners'''

* '''[https://www.owasp.org/index.php/OWASP_Merchandise#Banners Banner Examples]'''
* '''[http://dl.dropbox.com/u/38979962/owasp_gear_335x83_300dpi.pdf Cog wheel banner]'''
* '''[http://dl.dropbox.com/u/38979962/OWASP_Banner_300dpi.pdf/OWASP_Banner_300dpi.pdf Honeycomb banner]'''

'''Presentations'''

These slides are presented at Global AppSec Conferences by the Global Board to provide a high level overview of OWASP and to highlight some of the key initiatives at a Global level. This can be presented in its current form at OWASP Chapter meetings to enable a clarification of the mission and purpose of the local chapter. This can also be used or sent to the press/media when looking for an "overview of owasp".

* '''[https://www.owasp.org/images/3/35/2012Whereweare..Wherearewegoing.pdf 2012 Athens Where we are, Where we are going..]'''
* '''[https://www.owasp.org/images/8/83/FINAL-OWASP_Global_Board_Update_AppSecUS11.ppt.pdf 2011 Where we are, Where we are going..]'''

==Security Podcast with Jim Manico==
{| style="background-color: transparent"
|-
! width="200" align="center" | 
! width="1000" align="center" | 
|-
| align="center" | [[Image:Jim_Projects.jpg|100px]]
| align="justify" | The OWASP foundation presents the OWASP PODCAST SERIES hosted and produced by [mailto:jim@owasp.org Jim Manico]. Listen as interviews are conducted with OWASP volunteers, industry experts and leaders within the field of software security. Visit the [https://www.owasp.org/index.php/OWASP_Podcast Podcast Page] for more information.
|}

==OWASP Appsec Tutorial Series with Jerry Hoff==
{| style="background-color: transparent"
|-
! width="200" align="center" | 
! width="1000" align="center" | 
|-
| align="center" | [[Image:Jerry_Projects.jpg|100px]]
| align="justify" |The OWASP AppSec Tutorial Series project provides a video based means of conveying complex application security concepts in an easily accessible and understandable way. Each video is approximately 5-10 minutes long and highlights one or more specific application security concepts, tools, or methodologies. The goal of the project is quite simple and yet quite audacious - provide top notch application security video based training... for free! Visit the [https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series#Project_Lead Tutorial Series Page] for more information.
|}

==OWASP Press==

The OWASP press is a pattern for massive community collaboration on OWASP documentation projects with just-in-time publication. Visit the [https://www.owasp.org/index.php/OWASP_Press OWASP Press Page] for more information.

= Terminology =

== OWASP Project Infrastructure ==

*'''OWASP Project Lifecycle:''' The OWASP Projects Lifecycle represents a balance between keeping a very loose structure around OWASP projects, and ensuring that OWASP consumers are not confused about a project’s maturity and quality. The lifecycle stage allows consumers to easily identify mature projects, and projects that are proofs of concept, experimental, and classified as prototypes in their current state.

*'''Incubator Project:''' OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven, and development is still underway. The “OWASP Incubator” label allows OWASP consumers to readily identify a project’s maturity. The label also allows project leaders to leverage the OWASP name while their project is still maturing.

*'''Labs Project:''' OWASP Labs projects represent projects that have produced a deliverable of value. While these projects are typically not production ready, the OWASP community expects that an OWASP Labs project leader is producing releases that are at least ready for mainstream usage.

*'''Flagship Project:''' The OWASP Flagship designation is given to projects that have demonstrated superior maturity, established quality, and strategic value to OWASP and application security as a whole. OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining.

*'''Project Benefits:''' The standard list of resources and incentives made available to project leaders based on their project's current maturity level.

== OWASP Project Reviews ==

*'''Project Reviews:''' Project reviews are the method OWASP uses to establish a minimal baseline of project characteristics and release quality. Reviews are not mandatory, but they are necessary if a project leader wishes to graduate to the next level of maturity within the OWASP Global Projects infrastructure. Projects can be reviewed when an Incubator project wishes to graduate into the OWASP Labs designation, and project releases can be reviewed if they want the quality of their deliverable to be vouched for by OWASP.

*'''Project Reviewer Pool:''' The project reviewer pool is made up of veteran reviewers who have proven themselves dedicated to executing quality reviews of projects.

*'''Project Graduation:''' The Project Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs.

*'''Project Health Assessment:''' The Project Health Assessment is an optional process undertaken at the request of a project leader when he/she applies for Project Graduation The purpose of this assessment is to determine whether a project meets the minimum criteria of an OWASP Project outlined in the [https://docs.google.com/a/owasp.org/spreadsheet/ccc?key=0AllOCxlYdf1AdG5NZGhzTjZpT1RDcnRibjd0aXhfOUE#gid=1 Project Health Assessment Criteria Document].

*'''Project Release:''' A project release refers to the final deliverable a project produces. It is the final product of the project.

*'''Project Deliverable/Release Review:''' The Project Deliverable/Release Review is an optional process undertaken at the request of a project leader using the Project Deliverable Review Form. The purpose of this process is to review a project’s progress, and to make sure the project is heading in the right direction based on the roadmap they provided at project inception.

== OWASP Projects Processes ==

*'''Project Processes:''' The set of streamlined processes that exist to help projects move smoothly through the OWASP Project Lifecycle.

*'''Project Inception Process:''' The Project Inception Process is how a brand new idea becomes an OWASP Project. Such projects are labeled as OWASP Incubator projects. The process involves submitting the proposed project name, project leader information, project description, project roadmap, and selecting an appropriate open-source license for the project using the New Project Form on the Projects Portal.

*'''Project Donation Process:''' The Project Donation Process is used for a project that has an existing functional release, but is not currently associated with OWASP. This process is the primary mechanism by which individuals or organizations can transfer the ownership of their project’s copyright to OWASP.

*'''Project Transition Process:''' The Project Transition Process is used to transition leadership of a project to a new project leader. This is a simple automated process to transfer the relevant accounts, mailing lists, and other project resources to the new project leader.

*'''Project Abandonment Process:''' The Project Abandonment Process was put in place for those occasions in which a project leader is no longer able to manage their project, and has not been able to find a suitable replacement for the leader role. Project Abandonment can also occur when the project leader feels his/her project has become obsolete. Under these circumstances, the acting project leader is encourage do submit the Project Abandonment Form found in the Projects Portal.

*'''Incubator Graduation Process:''' The Incubator Graduation Process is an optional process undertaken at the request of a project leader using the Incubator Graduation Form. The purpose of this process is to move a project from the OWASP Incubator into the OWASP Labs.

== Projects at Conferences ==

*'''AppSec Conferences:''' OWASP AppSec conferences bring together industry, government, security researchers, and practitioners to discuss the state of the art in application security. This series was launched in the United States in 2004 and Europe in 2005. Global AppSec conferences are held annually in North America, Latin America, Europe, and Asia Pacific.

*'''Open Source Showcase:''' The Open Source Showcase is an OWASP AppSec Conference event module designed to give Open Source project leaders the opportunity to demo their projects.

*'''OWASP Project Track:''' The OWASP Project Track is an OWASP AppSec Conference event module designed to give OWASP Project leaders the opportunity to showcase their projects as an official conference presenter.

== OWASP Projects General ==

*'''OWASP Code of Ethics:''' The OWASP Code of Ethics are the set of guidelines and principles that the OWASP Foundation expects all of its members and conference attendees to abide by. A copy of the Code of Ethics can be found here in the [https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project#Code_of_Ethics OWASP About page].

= Sponsorships and Donations =


==Donate to OWASP Projects Division==
OWASP Projects, a global division of the OWASP Foundation, is run under the same world wide not-for-profit charitable status as all the foundation strategic groups. OWASP provides a platform for contributors to share their work while providing them with the project and community support they need throughout their project development. All OWASP Projects are run by volunteers and they rely on personal donations and sponsorship to continue their development. Donate to OWASP Projects, and we promise to spend your money wisely on open source initiatives.

'''This is how your money can help:'''

* $20 could help us spread the word on the importance of open source initiatives in the Application Security industry.
* $100 could help fund OWASP project demos at major conferences.
* $250 could help get our volunteer Project Leaders to speaking engagements.

[[Image:Donate_Button.jpg | link=http://www.regonline.com/Register/Checkin.aspx?EventID=1044369]]

==OWASP Project Sponsors==

'''Americas'''
*

'''Africa'''
*

'''Asia'''
*

'''Europe'''
*

'''Middle East'''
*

= PM Information =


==Samantha Groves: OWASP Projects Manager==
{| style="background-color: transparent"
|-
! width="200" align="center" | 
! width="1000" align="center" | 
|-
| align="center" | [[Image:Sam2.jpg|100px]]
| align="justify" |Samantha Groves is the Project Manager at OWASP. Samantha has led many projects in her career, some of which include website development, brand development, sustainability and socio-behavioral research projects, competitor analysis, event organization and management, volunteer engagement projects, staff recruitment and training, and marketing department organization and strategy implementation projects for a variety of commercial and not-for-profit organizations. She is eager to begin her work at OWASP and help the organization reach its project completion goals.

Samantha earned her MBA in International Management with a concentration in sustainability from Royal Holloway, University of London. She earned her Bachelor's degree majoring in Multimedia from The University of Advancing Technology in Mesa, Arizona, and she earned her Associate's degree from Scottsdale Community College in Scottsdale, Arizona. Additionally, Samantha recently attained her Prince2 (Foundation) project management certification.

Please see the [https://docs.google.com/a/owasp.org/document/d/1syHIiVA56KSR_T-enIMolMO6xSAZlWP86uvi_Ui8rPs/edit Project Manager Role Description] for more information. Please visit the [http://samanthagrovesblog.blogspot.com/ OWASP Project Manager Blog] for more information.
|}
 

==Projects Reports==

'''2013'''

*[https://www.owasp.org/index.php/GPC/Meetings/2013-04-01 GPC Meeting: January 04 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-11-01 GPC Meeting: January 11 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-18-01 GPC Meeting: January 18 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-25-01 GPC Meeting: January 25 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-01-02 GPC Meeting: February 01 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-08-02 GPC Meeting: February 08 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-15-02 GPC Meeting: February 15 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-22-02 GPC Meeting: February 22 2013 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-01-03 Project Manager Report: March 01 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-08-03 Project Manager Report: March 08 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-15-03 Project Manager Report: March 15 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-22-03 Project Manager Report: March 22 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-29-03 Project Manager Report: March 29 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-05-04 Project Manager Report: April 05 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-12-04 Project Manager Report: April 12 2013]
*[https://www.owasp.org/index.php/GPC/Meetings/2013-19-04 Project Manager Report: April 19 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-26-04 Project Manager Report: April 26 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-03-05 Project Manager Report: May 03 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-10-05 Project Manager Report: May 10 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-17-05 Project Manager Report: May 17 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-24-05 Project Manager Report: May 24 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-31-05 Project Manager Report: May 31 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-07-06 Project Manager Report: June 07 2013]
*[https://www.owasp.org/index.php/Projects/Reports/2013-14-06 Project Manager Report: June 14 2013]

'''2012'''

*[https://www.owasp.org/index.php/GPC/Meetings/2012-24-08 GPC Meeting: August 24 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-07-09 GPC Meeting: September 07 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-14-09 GPC Meeting: September 14 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-21-09 GPC Meeting: September 21 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-28-09 GPC Meeting: September 28 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-05-10 GPC Meeting: October 05 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-12-10 GPC Meeting: October 12 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-19-10 GPC Meeting: October 19 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-09-11 GPC Meeting: November 09 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-16-11 GPC Meeting: November 16 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-30-11 GPC Meeting: November 30 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-07-12 GPC Meeting: December 07 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-14-12 GPC Meeting: December 14 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-21-12 GPC Meeting: December 21 2012 Project Manager Report]
*[https://www.owasp.org/index.php/GPC/Meetings/2012-27-12 GPC Meeting: December 27 2012 Project Manager Report]

==Board Meeting Reports==

*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/August_13_2012 Board Meeting: August 2012 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/September_10_2012 Board Meeting: September 2012 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/October_08_2012 Board Meeting: October 2012 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/November_12_2012 Board Meeting: November 2012 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/December_10_2012 Board Meeting: December 2012 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/January_14_2013 Board Meeting: January 2013 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/February_11_2013 Board Meeting: February 2013 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/March_11_2013 Board Meeting: March 2013 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/April_05_2013 Board Meeting: April 2013 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/May_13_2013 Board Meeting: May 2013 Project Manager Report]
*[https://www.owasp.org/index.php/OWASP_Project_Manager_Activity_Reports/June_10_2013 Board Meeting: June 2013 Project Manager Report]

==Project Funds==

* [https://docs.google.com/a/owasp.org/spreadsheet/pub?hl=en_US&hl=en_US&key=0Atu4kyR3ljftdEdQWTczbUxoMUFnWmlTODZ2ZFZvaXc&output=html Chapter and Individual Project Funds]
* [https://www.owasp.org/index.php/Projects_Reboot_2012 Project Reboot 2012 Information]
* [https://www.owasp.org/images/a/ae/Project_Funds-Q1_2013.pdf Q1 2013: Funds Allocated to Projects]

==Project Grants==

* [https://docs.google.com/document/d/1MA3TI5ssclxvheV8At_ffu2Fuic55SDpOokS3AOvBUc/edit?usp=sharing OWASP Guidebooks Proposal]: This proposal as been completed and awarded.
** [https://www.owasp.org/images/1/18/Development_Guide_Project_Gantt.pdf OWASP Development Guide Plan]
** [https://www.owasp.org/images/e/e9/Testing_Guide_Project_Gantt.pdf OWASP Testing Guide Plan]
** [https://www.owasp.org/images/d/da/Code_Review_Project_Gantt.pdf OWASP Code Review Guide Plan]
* [https://docs.google.com/document/d/16ZFXaML8C7aDAZdyTMDDg4BzLr1vUTOz9eqmYE8ZW8U/edit?usp=sharing OWASP ESAPI Grant Proposal]: This proposal has been completed and submitted.
* [https://docs.google.com/document/d/1dBTaRr-yl8wGhGKxacWACznZhCZnJ_sZeAdN-b2xPlw/edit?usp=sharing OWASP ModSecurity CRS Proposal]: This proposal has been completed and submitted.
* Google Grants Proposal]: This proposal has been completed and awarded.
* European Commission Grant Proposal: This proposal has been completed and submitted.

==Project Presentations==

* [https://www.owasp.org/images/f/fb/OWASP_GLOBAL_PROJECTS.pdf OWASP Projects Presentation: Phoenix Chapter Talk]
* [https://www.owasp.org/images/b/bb/OWASP_Projects_Webinar.pdf OWASP Projects Webinar]
* [https://www.owasp.org/images/1/19/OWASP_PROJECTS_SOLUTIONS.pdf OWASP Project Infrastructure: Solutions]

==Projects Manger's Quarterly Strategic Objectives==

'''Goals and Objectives: 2013 Q2'''
#Identify and target 5-7 specific grants to pursue for 2013.
#Develop Brand Usage Guidelines for Projects.
#Need for consistent documentation of guidelines (similar to How To Host a Conference) that can apply to various events and venues.
#Volunteer Management - identification of skills and supervision required to engage volunteers productively.

*'''Ongoing Objectives for 2013'''
**Work with Project leaders to reach grant required milestones - ONGOING
**Develop a project charter outlining appropriate grant revenue spending and grant required milestones. - DUE IN SEPTEMBER - ONGOING
**Oversight of Marketing and Graphic Design deliverables (Phase 2/Phase 3) provided by 3rd party contractor

==Contact the Projects Manager==

If you need any help with anything projects related, or if you simply need some more information, please do not hesitate to contact the [http://owasp4.owasp.org/contactus.html OWASP Projects Manager, Samantha Groves].


= Contact US =


==OWASP Representation==
* [[User:Samantha Groves|Samantha Groves]]: OWASP Projects Manager

If you need any help with anything projects related, or if you simply need some more information, please do not hesitate to contact the [http://owasp4.owasp.org/contactus.html OWASP Projects Manager, Samantha Groves].


<headertabs />

Norway

2013-01-16T13:34:57Z

Eoftedal: /* Medlemsmøter 2012 */

== Welcome to the OWASP Norway Local Chapter ==

Welcome to the local Norway chapter homepage. The chapter leader is [mailto:erlend.oftedal@owasp.org Erlend Oftedal].
<paypal>Norway</paypal>

Se hvem som sitter i [[Norway Chapter styret]] og les [[Norway Chapter vedtekter]]. OWASP Norway Chapter er [http://w2.brreg.no/enhet/sok/detalj.jsp?orgnr=994253085 registrert i Bønnøysund] med organisasjonsnummer 994 253 085.

== Participation ==

OWASP chapter meetings are free and open to anyone interested in application security. We encourage members to give presentations on specific topics and to contribute to the local chapter by sharing their knowledge with others. Prior to participating with OWASP please review the [[Chapter Rules]].

To join the chapter mailing list, please visit our [https://lists.owasp.org/mailman/listinfo/owasp-norway mailing list] homepage. The list is used to discuss the meetings and to arrange meeting locations. You can also review the [https://lists.owasp.org/pipermail/owasp-norway/ email archives] to see what folks have been talking about. Please check the mailing list before coming to a meeting to confirm the location and time and to catch any last minute notes.

== Medlemsmøter 2012 ==

=== [[OWASP Norway - Hall of fame ]] ===

[[Forslagskasse]] for tema

Hvis du ikke er på [https://lists.owasp.org/mailman/listinfo/owasp-norway e-postlista] så meld deg på!

=== Neste møte ===

==== Medlemsmøte: 7. Februar, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/98525562/ Påmelding på meetup.com]]
'''Tema:''' Crossing Domains by Crossing Origins

=== Tidligere møter ===

==== Medlemsmøte: 18. Oktober, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Påmelding/lokasjon/agenda:''' [[http://www.meetup.com/OWASP-Norway/events/84322982/ Påmelding på meetup.com]]
'''Tema:''' Sikkerhet i det norske eValg-systemet

==== Medlemsmøte: 24. april, kl 19:30 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' -,
'''Adresse:''' [http://maps.google.com/maps?q=Tordenskiolds+gate+3%2C+Oslo Mesh Norway, Tordenskiolds gate 3],
'''Påmelding:''' [http://www.doodle.com/t7kaxy7a5u7v6u6s klikk her]

Tema denne gang er sikkerhet i mobile applikasjoner. Det blir først en introduksjon, deretter kommer
Martin Knobloch fra OWASP Nederland for å snakke om iGoat og GoatDroid, for så å dele erfaringer fra
en code review.

Slides:

[[Media:Mobil - Introduksjon til applikasjonssikkerhet.pdf|OWASP Mobile Top 10]] - Ståle Pettersen

[[Media:OWASP-mobile aps.pdf|OWASP Mobile]] - Martin Knobloch

==== Medlemsmøte: 19. mars, kl 17:00 ====
'''Ansvarlig:''' Erlend Oftedal ,
'''Sponsor:''' F5,
'''Adresse:''' [http://maps.google.com/maps?q=the+dubliner+oslo&hl=en&client=ubuntu&channel=fs&fb=1&hq=the+dubliner&hnear=0x46416e61f267f039:0x7e92605fd3231e9a,Oslo,+Norway&cid=0,0,12890284609415510924&t=h&z=15&iwloc=A The Dubliner],
'''Påmelding:''' [http://www.doodle.com/d4rfandvnakqydc6 klikk her]
{|
|'''"Web Application Access Control Design Excellence"''', Jim Manico 

Access Control is a necessary security control at almost every layer within a web application. This talk will discuss
several of the key access control anti-patterns commonly found during website security audits. These access control anti-patterns
include hard-coded security policies, lack of horizontal access control, and "fail open" access control mechanisms. In reviewing
these and other access control problems, we will discuss and design a positive access control mechanism that is data contextual,
activity based, configurable, flexible, and deny-by-default - among other positive design attributes that make up a robust
web-based access-control mechanism.
|}

== Lokale Nyheter ==

== Tidligere år ==

=== [[Medlemsmøter 2011]] ===
=== [[Medlemsmøter 2010]] ===
=== [[Medlemsmøter 2009]] ===
=== [[Medlemsmøter 2008]] ===

[[Category:OWASP Chapter]]
[[Category:Norway]]
[[Category:Europe]]

REST Security Cheat Sheet

2012-12-13T07:26:46Z

Eoftedal:

= Introduction =

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] or REpresentational State Transfer is a means of expressing specific entities in a system by URL path elements, REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URL's rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and Session Management =

RESTful web services should use session based authentication, either by establishing a session token via a POST, or using an API key as a POST body argument or as a cookie. Usernames and passwords, session tokens and API keys should not appear in the URL, as this can be captured in web server logs and makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS and API Key in URL)

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider just using the session token or API key to maintain client state in a server side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt and change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry, whereas for the librarian, both of these are valid uses.

== Whitelist Allowable Methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>POST</tt> would update an existing entity, <tt>PUT</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs will work, all others return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=18 Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Direct object references ==

It may seem obvious, but if you had a bank account REST web service, you have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly insane. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

Please make sure you understand how to protect against [[Top_10_2010-A4-Insecure_Direct_Object_References|direct object references]] in the OWASP Top 10 2010.

= Input Validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and computer" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate Incoming Content-Types ==

When POSTing or PUTing new data, the client will specify the a Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The client should never assume the Content-Type, but always check that the Content-Type header and the content is of the same type. A lack of Content-Type header or an unexpected Content-Type header, should result in the server rejecting the Content with a <tt>406 Not Acceptable</tt> response.

== Validate Response Types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML Input Validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

= Output Encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is to prevent arbitrary JavaScript remote code execution within the browser, or if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user supplied data properly to prevent the execution of user supplied input on the browser.

When inserting values into the browser DOM, strongly consider using .value/.innerText/.textContent rather than .innerHTML updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable, and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless completely read only public information, the use of TLS should be mandated, particularly where credentials, updates, deletions and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Erlend Oftedal - erlend.oftedal@owasp.org 
Andrew van der Stock - vanderaj@owasp.org 

[[Category:Cheatsheets]]