OWASP - User contributions [en]

HttpOnly

2017-08-24T20:02:30Z

Markgordon: Corrected a spelling error

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HttpOnly.

<h3 style="color:#4682B4"> <u> Who developed HttpOnly? When? </u> </h3>

According to a daily blog article by [http://www.networkcomputing.com/careers/no-cookie-you/1270585242 Jordan Wiens, “No cookie for you!”], HttpOnly cookies were first implemented in 2002 by Microsoft Internet Explorer developers for Internet Explorer 6 SP1.

<h3 style="color:#4682B4"> <u> What is HttpOnly? </u> </h3>

According to the [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Microsoft Developer Network], HttpOnly is an ''additional flag'' included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).

*The example below shows the syntax used within the '''HTTP response header''':

Set-Cookie: <name>=<value>[; <Max-Age>=<age>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

If a browser does not support HttpOnly and a website attempts to set an HttpOnly cookie, the HttpOnly flag will be ignored by the browser, thus creating a traditional, script accessible cookie. As a result, the cookie (typically your session cookie) becomes vulnerable to theft of modification by malicious script. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating].

<h3 style="color:#4682B4"> <u>Mitigating the Most Common XSS attack using HttpOnly</u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks target theft of session cookies. A server could help mitigate this issue by setting the HttpOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client.

If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser ''returns an empty string'' as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website.

<h5 style="color:#2E8B57"> <u>Using Java to Set HttpOnly</u> </h5>

Since Java Enterprise Edition 6 (JEE 6), which adopted Java Servlet 3.0 technology, it's programmatically easy to set the HttpOnly flag on a cookie.

In fact <code>setHttpOnly</code> and <code>isHttpOnly</code> methods are available in the <code>Cookie</code> interface [http://java.sun.com/javaee/6/docs/api/javax/servlet/http/Cookie.html#setHttpOnly%28boolean%29], and also for session cookies (JSESSIONID) [http://java.sun.com/javaee/6/docs/api/javax/servlet/SessionCookieConfig.html#setHttpOnly%28boolean%29]:
Cookie cookie = getMyCookie("myCookieName");
cookie.setHttpOnly(true);

Moreover, since JEE 6 it's also declaratively easy setting <code>HttpOnly</code> flag in a session cookie by applying the following configuration in the deployment descriptor <code>WEB-INF/web.xml</code>:
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>

For Java Enterprise Edition versions ''prior'' to JEE 6 a common '''workaround''' is to overwrite the <code>SET-COOKIE</code> HTTP response header with a session cookie value that explicitly appends the <code>HttpOnly</code> flag:
String sessionid = request.getSession().getId();
// be careful overwriting: JSESSIONID may have been set with other flags
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; HttpOnly");

In this context, overwriting, despite appropriate for the <code>HttpOnly</code> flag, is discouraged because the JSESSIONID may have been set with other flags. A better workaround is taking care of the previously set flags or using the [[ESAPI#Java_EE]] library: in fact the <code>addCookie</code> method of the <code>SecurityWrapperResponse</code> [http://code.google.com/p/owasp-esapi-java/source/browse/tags/esapi-2.0.1/src/main/java/org/owasp/esapi/filters/SecurityWrapperResponse.java] takes care of previously set flags for us. So we could write a servlet filter as the following one:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest httpServletRequest = (HttpServletRequest) request;
HttpServletResponse httpServletResponse = (HttpServletResponse) response;
// if errors exist then create a sanitized cookie header and continue
SecurityWrapperResponse securityWrapperResponse = new SecurityWrapperResponse(httpServletResponse, "sanitize");
Cookie[] cookies = httpServletRequest.getCookies();
if (cookies != null) {
for (int i = 0; i < cookies.length; i++) {
Cookie cookie = cookies[i];
if (cookie != null) {
// ESAPI.securityConfiguration().getHttpSessionIdName() returns JSESSIONID by default configuration
if (ESAPI.securityConfiguration().getHttpSessionIdName().equals(cookie.getName())) {
securityWrapperResponse.addCookie(cookie);
}
}
}
}
filterChain.doFilter(request, response);
}

Some web application servers, that implement JEE 5, and servlet containers that implement Java Servlet 2.5 (part of JEE 5), also allow creating HttpOnly session cookies:

* '''Tomcat 6''' In <code>context.xml</code> set the <code>context</code> tag's attribute <code>useHttpOnly</code> [http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Common_Attributes] as follow:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/myWebApplicationPath" useHttpOnly="true">

* '''JBoss 5.0.1''' and '''JBOSS EAP 5.0.1''' In <code>\server\<myJBossServerInstance>\deploy\jbossweb.sar\context.xml</code> set the <code>SessionCookie</code> tag [https://community.jboss.org/message/598558#598558] as follow:
<Context cookies="true" crossContext="true">
<SessionCookie secure="true" httpOnly="true" />

* <b>IBM Websphere</b> offer HTTPOnly for session cookies as a configuration option.
http://pic.dhe.ibm.com/infocenter/tivihelp/v33r1/topic/com.ibm.mam.inswas.doc/install/t_configuringthehttponlyattribute.html

<h5 style="color:#2E8B57"> <u>Using .NET to Set HttpOnly</u> </h5>

*By ''default'', '''.NET 2.0''' sets the HttpOnly attribute for
*#Session ID
*#Forms Authentication cookie

In .NET 2.0, HttpOnly can also be set via the HttpCookie object for all custom application cookies
*Via '''web.config''' in the system.web/httpCookies element
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
C# Code:
HttpCookie myCookie = new HttpCookie("myCookie");
myCookie.HttpOnly = true;
Response.AppendCookie(myCookie);

VB.NET Code:
Dim myCookie As HttpCookie = new HttpCookie("myCookie")
myCookie.HttpOnly = True
Response.AppendCookie(myCookie)

*However, in '''.NET 1.1''', you would have to do this ''manually'', e.g.,
Response.Cookies[cookie].Path += ";HttpOnly";

<h5 style="color:#2E8B57"> <u>Using Python (cherryPy) to Set HttpOnly</u> </h5>

Python Code (cherryPy):<br>
To use HTTP-Only cookies with Cherrypy sessions just add the following line in your configuration file:<br>
tools.sessions.httponly = True<br>
If you use SLL you can also make your cookies secure (encrypted) to avoid "man-in-the-middle" cookies reading with:<br>
tools.sessions.secure = True<br>

<h5 style="color:#2E8B57"> <u> Using PHP to set HttpOnly </u> </h5>
PHP supports setting the HttpOnly flag since version 5.2.0 (November 2006).

For session cookies managed by PHP, the flag is set either permanently in php.ini [http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-httponly PHP manual on ''HttpOnly''] through the parameter:
session.cookie_httponly = True
or in and during a script via the function[http://pl.php.net/manual/en/function.session-set-cookie-params.php]:
void session_set_cookie_params ( int $lifetime [, string $path [, string $domain
[, bool $secure= false [, bool $httponly= false ]]]] )
For application cookies last parameter in setcookie() sets HttpOnly flag[http://pl.php.net/setcookie]:
bool setcookie ( string $name [, string $value [, int $expire= 0 [, string $path
[, string $domain [, bool $secure= false [, bool $httponly= false ]]]]]] )

===Web Application Firewalls===
If code changes are infeasible, web application firewalls can be used to add HttpOnly to session cookies:

* Mod_security - using SecRule and Header directives[http://blog.modsecurity.org/2008/12/fixing-both-missing-httponly-and-secure-cookie-flags.html]
* ESAPI WAF[http://code.google.com/p/owasp-esapi-java/downloads/list] using ''add-http-only-flag'' directive[http://www.slideshare.net/llamakong/owasp-esapi-waf-appsec-dc-2009]

==Browsers Supporting HttpOnly==

Using WebGoat's HttpOnly lesson, the following web browsers have been tested for HttpOnly support. If the browsers enforces HttpOnly, a client side script will be unable to read or write the session cookie. However, there is currently no prevention of reading or writing the session cookie via a XMLHTTPRequest.

Note: These results may be out of date as this page is not well maintained. A great page that is focused on keeping up with the status of browsers is at: http://www.browserscope.org/?category=security. Just look at the HttpOnly column. The Browserscope site does not provide as much detail on HttpOnly as this page, but provides lots of other details this page does not.

Our results as of Feb 2009 are listed below in '''table 1'''.

{| width="100%" border="2" align="center"
|+ '''Table 1:''' Browsers Supporting HttpOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Prevents Reads'''
! style="background:black; color:white" | '''Prevents Writes'''
! style="background:black; color:white" | '''Prevents Read within XMLHTTPResponse*'''
|-
| Microsoft Internet Explorer
| align="center" | 8 Beta 2
| align="center" | Yes
| align="center" | Yes
| align="center" | Partially (set-cookie is protected, but not set-cookie2, see [http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx]). Fully patched IE8 passes http://ha.ckers.org/httponly.cgi
|-
| Microsoft Internet Explorer
| align="center" | 7
| align="center" | Yes
| align="center" | Yes
| align="center" | Partially (set-cookie is protected, but not set-cookie2, see [http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx]). Fully patched IE7 passes http://ha.ckers.org/httponly.cgi
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1)
| align="center" | Yes
| align="center" | No
| align="center" | No (Possible that ms08-069 fixed IE 6 too, please verify with http://ha.ckers.org/httponly.cgi and update this page!)
|-
|-
| Microsoft Internet Explorer
| align="center" | 6 (fully patched)
| align="center" | Yes
| align="center" | Unknown
| align="center" | Yes
|-
| Mozilla Firefox
| align="center" | 3.0.0.6+
| align="center" | Yes
| align="center" | Yes
| align="center" | Yes (see [http://manicode.blogspot.com/2009/02/firefox-3006-httponly-champion.html])
|-
| Netscape Navigator
| align="center" | 9.0b3
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Opera
| align="center" | 9.23
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Opera
| align="center" | 9.50
| align="center" | Yes
| align="center" | No
| align="center" | No
|-
| Opera
| align="center" | 11
| align="center" | Yes
| align="center" | Unknown
| align="center" | Yes
|-
| Safari
| align="center" | 3.0
| align="center" | No
| align="center" | No
| align="center" | No (almost yes, see [https://bugs.webkit.org/show_bug.cgi?id=10957])
|-
| Safari
| align="center" | 5
| align="center" | Yes
| align="center" | Yes
| align="center" | Yes
|-
| iPhone (Safari)
| align="center" | iOS 4
| align="center" | Yes
| align="center" | Yes
| align="center" | Yes
|-
| Google's Chrome
| align="center" | Beta (initial public release)
| align="center" | Yes
| align="center" | No
| align="center" | No (almost yes, see [https://bugs.webkit.org/show_bug.cgi?id=10957])
|-
| Google's Chrome
| align="center" | 12
| align="center" | Yes
| align="center" | Yes
| align="center" | Yes
|-
| Android
| align="center" | Android 2.3
| align="center" | Unknown
| align="center" | Unknown
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still read the session cookie in a response to an '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

As of 2011, 99% of browsers and most web application frameworks support HttpOnly<ref>[http://blog.fortify.com/blog/2011/11/02/Misunderstandings-on-HttpOnly-Cookie Misunderstandings on HttpOnly Cookie]</ref>.

== Using WebGoat to Test for HttpOnly Support ==

The goal of this section is to provide a step-by-step example of testing your browser for HttpOnly support.

<h3 style="color:#4682B4"> <u> WARNING</u> </h3>

The OWASP WEBGOAT HttpOnly lab is broken and does not show IE 8 Beta 2 with ms08-069 as complete in terms of HttpOnly XMLHTTPRequest header leakage protection. This error is being tracked via http://code.google.com/p/webgoat/issues/detail?id=18.

<h3 style="color:#4682B4"> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HttpOnly Test Lesson]]

Assuming you have installed and launched WebGoat, begin by navigating to the '''‘HttpOnly Test’ lesson''' located within the Cross-Site Scripting ('''XSS''') category. After loading the ‘HttpOnly Test’ lesson, as shown in '''figure 1''', you are now able to begin testing web browsers supporting HttpOnly.

<h3 style="color:#4682B4"> <u> Lesson Goal </u> </h3>

If the ''HttpOnly flag'' is set, then your browser should not allow a client-side script to access the session cookie. Unfortunately, since the attribute is relatively new, several browsers may neglect to handle the new attribute properly.

The '''purpose''' of this lesson is to test whether your browser supports the '''HttpOnly cookie flag'''. ''Note the value of the'' '''''unique2u cookie'''''. If your browser supports HttpOnly, and you ''enable'' it for a cookie, a client-side script should NOT be able to read OR write to that cookie, but the browser can still send its value to the server. However, some browsers only prevent client side read access, but do not prevent write access.

<h3 style="color:#4682B4"> <u> Testing Web Browsers for HttpOnly Support </u> </h3>

The following test was performed on two browsers, '''Internet Explorer 7''' and '''Opera 9.22''', to demonstrate the results when the HttpOnly flag is enforced properly. As you will see, IE7 properly enforces the HttpOnly flag, whereas Opera does not properly enforce the HttpOnly flag.

<h5 style="color:#2E8B57"> <u> Disabling HttpOnly </u> </h5>

1) Select the option to '''turn HttpOnly off''' as shown below in '''figure 2'''.

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HttpOnly]]

2) After turning HttpOnly off, select the '''“Read Cookie”''' button.
*An alert dialog box will display on the screen notifying you that ''since HttpOnly was not enabled'', the '''‘unique2u’ cookie''' was successfully read as shown below in '''figure 3'''.

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HttpOnly Off]]

3) With HttpOnly remaining disabled, select the '''“Write Cookie” ''' button.

*An alert dialog box will display on the screen notifying you that ''since HttpOnly was not enabled'', the '''‘unique2u’ cookie''' was successfully modified on the client side as shown below in '''figure 4'''.

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|Figure 4 - Cookie Successfully Written with HttpOnly Off]]

*As you have seen thus far, '''browsing without HttpOnly''' on is a potential '''''threat'''''. Next, we will '''enable HttpOnly''' to demonstrate how this flag protects the cookie.

<h5 style="color:#2E8B57"> <u> Enabling HttpOnly </u> </h5>

4) Select the ''radio button'' to enable HttpOnly as shown below in '''figure 5'''.

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HttpOnly]]

5) After enabling HttpOnly, select the '''"Read Cookie"''' button.

*If the browser enforces the HttpOnly flag properly, an alert dialog box will display only the session ID rather than the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 6 - Enforced Cookie Read Protection]]

*However, if the browser does not enforce the HttpOnly flag properly, an alert dialog box will display both the '''‘unique2u’ cookie''' and session ID as shown below in '''figure 7'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*Finally, we will test if the browser allows '''write access''' to the cookie with HttpOnly enabled.

6) Select the '''"Write Cookie"''' button.

*If the browser enforces the HttpOnly flag properly, client side modification will be unsuccessful in writing to the '''‘unique2u’ cookie''' and an alert dialog box will display only containing the session ID as shown below in '''figure 8'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*However, if the browser does not enforce the write protection property of HttpOnly flag for the '''‘unique2u’ cookie''', the cookie will be successfully modified to ''HACKED'' on the client side as shown below in '''figure 9'''.

[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]

== References ==

# [https://cwe.mitre.org/data/definitions/1004.html CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag]
# Wiens, Jordan [http://www.networkcomputing.com/careers/no-cookie-you/1270585242 "No cookie for you!"]
# [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]
# Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]
# MSDN. [http://msdn.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx Setting the HttpOnly propery in .NET]
# [http://seckb.yehg.net/2012/06/xss-gaining-access-to-httponly-cookie.html XSS: Gaining access to HttpOnly Cookie in 2012]
# [http://stackoverflow.com/questions/13147113/setting-an-httponly-cookie-with-javax-servlet-2-5 Setting HttpOnly in Java]
<references />

User talk:Markgordon

2017-05-22T03:12:36Z

Markgordon: Blanked the page

User talk:Markgordon

2017-05-22T03:12:01Z

Markgordon:

I'm Mark Gordon, living & working in Canada. I'm a software developer with a strong interest in infosec.

Talk:OWASP Anti-Ransomware Guide Projec

2017-05-15T20:54:56Z

Markgordon: This page created after following an @OWASP tweet. Why this page?!

I understand OWASP's purpose to be helping developers create software without vulnerabilities. "Anti-ransomware" is more a matter of operations and operating systems.

Arrived at this page from an [https://twitter.com/owasp/status/864208775116443649 OWASP tweet]: "Ensure your firewall is configured for egress filtering as well as ingress filtering. #Ransomware #wannacry"

User:Markgordon

2016-05-12T05:17:49Z

Markgordon: Who, me?

Canadian software developer with a penchant for infosec and craft beer.

Talk:Key Management Cheat Sheet

2016-05-12T05:11:26Z

Markgordon: Key rotation?

Any plans to discuss key rotation?

Edmonton

2016-04-05T05:14:53Z

Markgordon: /* Resurrection */

== Resurrection ==
'''Update, 2016.4.4'''. After a nine year rest, the Edmonton chapter has been resurrected! Please stay tuned

{{Chapter Template|chaptername=Edmonton|extra=The chapter leader is [mailto:mark.gordon@owasp.org Mark Gordon]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-edmonton|emailarchives=http://lists.owasp.org/pipermail/owasp-edmonton}}

==== Local News ====

==== Chapter Meetings ====
Our chapter's LAST meeting took place April 10, 2007 at 6:00 PM. The topic was "Using OWASP WSFuzzer for Web Service Penetration Testing", by Mark Gordon.

You don't need to bring an understanding of web services to the talk. After a 5-minute introduction to the basics of web services you will know plenty of new buzzwords, enough to impress your friends and befuddle your enemies. After the intro Mark will demonstrate several concrete examples of how [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project WSFuzzer] helps automate testing web services for vulnerabilities. If time permits we can also discuss other details of web services such as using Akamai for better performance and the acronym soup that is the world of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA].

Previous meetings covered:
* OWASP's Top Ten Project
* OWASP's WebGoat insecure web application
* Cross Site Scripting Attacks (Yegor's [http://www.owasp.org/images/5/5e/XssYegorJbanov.pdf slideshow])
* Pub Night(!); discussed strategies for secure use of personal web applications
* "Building Defensible Web App Architectures", by Jason Meltzer of Strange Research

==== Edmonton OWASP Chapter Leaders ====
The chapter leader is_________________
__NOTOC__
<headertabs/>
[[Category:Alberta]]

Edmonton

2016-04-04T22:23:36Z

Markgordon: Announce resurrection of chapter.

==== Resurrection ====
'''Update, 2016.4.4'''. After a nine year rest, the Edmonton chapter has been resurrected! Please stay tuned

{{Chapter Template|chaptername=Edmonton|extra=The chapter leader is [mailto:mark.gordon@owasp.org Mark Gordon]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-edmonton|emailarchives=http://lists.owasp.org/pipermail/owasp-edmonton}}
==== Local News ====

==== Chapter Meetings ====
Our chapter's LAST meeting took place April 10, 2007 at 6:00 PM. The topic was "Using OWASP WSFuzzer for Web Service Penetration Testing", by Mark Gordon.

You don't need to bring an understanding of web services to the talk. After a 5-minute introduction to the basics of web services you will know plenty of new buzzwords, enough to impress your friends and befuddle your enemies. After the intro Mark will demonstrate several concrete examples of how [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project WSFuzzer] helps automate testing web services for vulnerabilities. If time permits we can also discuss other details of web services such as using Akamai for better performance and the acronym soup that is the world of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA].

Previous meetings covered:
* OWASP's Top Ten Project
* OWASP's WebGoat insecure web application
* Cross Site Scripting Attacks (Yegor's [http://www.owasp.org/images/5/5e/XssYegorJbanov.pdf slideshow])
* Pub Night(!); discussed strategies for secure use of personal web applications
* "Building Defensible Web App Architectures", by Jason Meltzer of Strange Research

==== Edmonton OWASP Chapter Leaders ====
The chapter leader is_________________
__NOTOC__
<headertabs/>
[[Category:Alberta]]

Edmonton

2016-04-04T22:19:55Z

Markgordon: /* Chapter Meetings */

{{Chapter Template|chaptername=Edmonton|extra=The chapter leader is [mailto:mark.gordon@owasp.org Mark Gordon]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-edmonton|emailarchives=http://lists.owasp.org/pipermail/owasp-edmonton}}
==== Local News ====

==== Chapter Meetings ====
Our chapter's LAST meeting took place April 10, 2007 at 6:00 PM. The topic was "Using OWASP WSFuzzer for Web Service Penetration Testing", by Mark Gordon.

You don't need to bring an understanding of web services to the talk. After a 5-minute introduction to the basics of web services you will know plenty of new buzzwords, enough to impress your friends and befuddle your enemies. After the intro Mark will demonstrate several concrete examples of how [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project WSFuzzer] helps automate testing web services for vulnerabilities. If time permits we can also discuss other details of web services such as using Akamai for better performance and the acronym soup that is the world of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA].

Previous meetings covered:
* OWASP's Top Ten Project
* OWASP's WebGoat insecure web application
* Cross Site Scripting Attacks (Yegor's [http://www.owasp.org/images/5/5e/XssYegorJbanov.pdf slideshow])
* Pub Night(!); discussed strategies for secure use of personal web applications
* "Building Defensible Web App Architectures", by Jason Meltzer of Strange Research

==== Edmonton OWASP Chapter Leaders ====
The chapter leader is_________________
__NOTOC__
<headertabs/>
[[Category:Alberta]]

Talk:Bytecode obfuscation

2016-01-17T21:51:22Z

Markgordon: This page may not be appropriate for OWASP to host.

==Status==
Needs review
==Authors==
* Pierre Parrend

==Meta==
Why does the ''Open'' Web Application Security Project contain a page on bytecode obfuscation?!

==Reviewers==
*

==General Discussion==

Relative to the categories of this article:
* the 'Countermeasure' category does not contain adequate sub-category. Should we add a 'Code Protection' one ?
* I put the article in the category 'Howto', because it is a pragmatic tutorial. However, it is not named 'Howto perform code obfuscation', and so looks strange in the list of howtos: https://www.owasp.org/index.php/Category:How_To.
This should be OK, there's another article "Webscarab getting started" which also doesn't start with howto" - [[User:Stephendv|Stephendv]] 02:00, 16 November 2006 (EST)

Hashing Java

2016-01-17T04:57:30Z

Markgordon: Fixed spelling error.

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>

==Introduction==

This page helps Java developers hash passwords safely. We rely on OWASP's [[Password Storage Cheat Sheet]] to explain hashing best practice and theory.

==Java Example==

public static byte[] hashPassword( final char[] password, final byte[] salt, final int iterations, final int keyLength ) {

try {
SecretKeyFactory skf = SecretKeyFactory.getInstance( "PBKDF2WithHmacSHA512" );
PBEKeySpec spec = new PBEKeySpec( password, salt, iterations, keyLength );
SecretKey key = skf.generateSecret( spec );
byte[] res = key.getEncoded( );
return res;

} catch( NoSuchAlgorithmException | InvalidKeySpecException e ) {
throw new RuntimeException( e );
}
}

==Guidance==

The password and salt arguments are arrays, as is the result of the hashPassword function.
Sensitive data should be ''cleared'' after you have used it (set the array elements to zero).

The example uses a Password Based Key Derivation Function 2 (PBKDF2), as discussed in the [[Password Storage Cheat Sheet]].

The ''salt'' argument should be random data and vary for each user. It should be at least 32 bytes long. Remember to save the salt with the hashed password!

The ''iterations'' argument specifies how many times the PBKDF2 executes its underlying algorithm. A higher value is safer. You need to experiment on hardware equivalent to your production systems. As a starting point, find a value that requires one half second to execute. Scaling to huge number of users is beyond the scope of this document. Remember to save the value of iterations with the hashed password!

A keyLength of 256 is safe.

If the example code generates a NoSuchAlgorithmException, replace PBKDF2WithHmacSHA512 with PBKDF2WithHmacSHA1. Both are adequate to the task but you may be criticized when people see "SHA1" in the specification (SHA1 can be unsafe outside of the context of PBKDF2).

The SecretKeyFactory and PBEKeySpec classes have been part of Java SE since version 1.4.

==Reference==

See ''Iron-Clad Java: Building Secure Web Applications'' by Manico and Detlefsen, 2015, Oracle Press.

[[Category:OWASP Java Project]]

Hashing Java

2016-01-17T04:48:58Z

Markgordon: Missing closing brace

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>

==Introduction==

This page helps Java developers hash passwords safely. We rely on OWASP's [[Password Storage Cheat Sheet]] to explain hashing best practice and theory.

==Java Example==

public static byte[] hashPassword( final char[] password, final byte[] salt, final int iterations, final int keyLength ) {

try {
SecretKeyFactory skf = SecretKeyFactory.getInstance( "PBKDF2WithHmacSHA512" );
PBEKeySpec spec = new PBEKeySpec( password, salt, iterations, keyLength );
SecretKey key = skf.generateSecret( spec );
byte[] res = key.getEncoded( );
return res;

} catch( NoSuchAlgorithmException | InvalidKeySpecException e ) {
throw new RuntimeException( e );
}
}

==Guidance==

The password and salt arguments are arrays, as is the result of the hashPassword function.
Sensitive data should be ''cleared'' after you have used it (set the array elements to zero).

The example uses a Password Based Key Derivation Function 2 (PBKDF2), as discussed in the [[Password Storage Cheat Sheet]].

The ''salt'' argument should be random data and vary for each user. It should be at least 32 bytes long. Remember to save the salt with the hashed password!

The ''interations'' argument specifies how many times the PBKDF2 executes its underlying algorithm. A higher value is safer. You need to experiment on hardware equivalent to your production systems. As a starting point, find a value that requires one half second to execute. Scaling to huge number of users is beyond the scope of this document. Remember to save the value of iterations with the hashed password!

A keyLength of 256 is safe.

If the example code generates a NoSuchAlgorithmException, replace PBKDF2WithHmacSHA512 with PBKDF2WithHmacSHA1. Both are adequate to the task but you may be criticized when people see "SHA1" in the specification (SHA1 can be unsafe outside of the context of PBKDF2).

The SecretKeyFactory and PBEKeySpec classes have been part of Java SE since version 1.4.

==Reference==

See ''Iron-Clad Java: Building Secure Web Applications'' by Manico and Detlefsen, 2015, Oracle Press.

[[Category:OWASP Java Project]]

Hashing Java

2016-01-16T21:17:18Z

Markgordon: Reworked code to avoid possible copyright issue. Switched PBKDF2WithHmacSHA1 to PBKDF2WithHmacSHA512 in case some code reviewer has read about SHA1 issues(!).

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>

==Introduction==

This page helps Java developers hash passwords safely. We rely on OWASP's [[Password Storage Cheat Sheet]] to explain hashing best practice and theory.

==Java Example==

public static byte[] hashPassword( final char[] password, final byte[] salt, final int iterations, final int keyLength ) {

try {
SecretKeyFactory skf = SecretKeyFactory.getInstance( "PBKDF2WithHmacSHA512" );
PBEKeySpec spec = new PBEKeySpec( password, salt, iterations, keyLength );
SecretKey key = skf.generateSecret( spec );
byte[] res = key.getEncoded( );
return res;

} catch( NoSuchAlgorithmException | InvalidKeySpecException e ) {
throw new RuntimeException( e );
}

==Guidance==

The password and salt arguments are arrays, as is the result of the hashPassword function.
Sensitive data should be ''cleared'' after you have used it (set the array elements to zero).

The example uses a Password Based Key Derivation Function 2 (PBKDF2), as discussed in the [[Password Storage Cheat Sheet]].

The ''salt'' argument should be random data and vary for each user. It should be at least 32 bytes long. Remember to save the salt with the hashed password!

The ''interations'' argument specifies how many times the PBKDF2 executes its underlying algorithm. A higher value is safer. You need to experiment on hardware equivalent to your production systems. As a starting point, find a value that requires one half second to execute. Scaling to huge number of users is beyond the scope of this document. Remember to save the value of iterations with the hashed password!

A keyLength of 256 is safe.

If the example code generates a NoSuchAlgorithmException, replace PBKDF2WithHmacSHA512 with PBKDF2WithHmacSHA1. Both are adequate to the task but you may be criticized when people see "SHA1" in the specification (SHA1 can be unsafe outside of the context of PBKDF2).

The SecretKeyFactory and PBEKeySpec classes have been part of Java SE since version 1.4.

==Reference==

See ''Iron-Clad Java: Building Secure Web Applications'' by Manico and Detlefsen, 2015, Oracle Press.

[[Category:OWASP Java Project]]

Hashing Java

2016-01-16T00:39:18Z

Markgordon: Remove theory & motivation of hashing. Instead, direct the reader to OWASP Password Storage Cheat Sheet. Replace example guidance based on Manico & Detlefsen's Iron-Clad Java: Building Secure Web Applications

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
<br/>

==Introduction==

This page helps Java developers hash passwords safely. We rely on OWASP's [[Password Storage Cheat Sheet]] to explain the theory of hashing. Here we discuss only how Java developers can safely implement the advice in that cheat sheet.

==Java Example==

public static byte[] hashPassword( final char[] password, final byte[] salt, final int iterations, final int keyLength ) {

try {
return SecretKeyFactory.getInstance( "PBKDF2WithHmacSHA1" ).generateSecret(
new PBEKeySpec( password, salt, iterations, keyLength )).getEncoded( );

} catch( NoSuchAlgorithmException | InvalidKeySpecException e ) {
throw new RuntimeException( e );
}

==Guidance==

The password and salt arguments are arrays, as is the result of the hashPassword function.
Sensitive data should be ''cleared'' after you have used it (generally, this means set the data to nulls).

The example uses a Password Based Key Derivation Function 2 (PBKDF2), as discussed in [[Password Storage Cheat Sheet]].

The ''salt'' argument should be random data and vary for each user. It should be at least 32 bytes long. Remember to save the salt with the hashed password!

The ''interations'' argument specifies how many times the PBKDF2 executes its underlying algorithm. A higher value is safer. You need to experiment on hardware equivalent to your production systems. As a starting point, find a value that requires one half second to execute. Scaling to huge number of users is beyond the scope of this document. Remember to save the value of iterations with the hashed password!

A keyLength of 256 is safe.

The SecretKeyFactory and PBEKeySpec classes have been part of Java SE since version 1.4.

==Reference==

See ''Iron-Clad Java: Building Secure Web Applications'' by Manico and Detlefsen, 2015, Oracle Press.

[[Category:OWASP Java Project]]

Hashing Java

2015-12-16T19:04:53Z

Markgordon: Grammatical correction to test my ability to edit this page

{{taggedDocument
| type=old
| lastRevision=2010-08-30
| comment=The page should be updated or removed.
}}

{|
|-
! width="700" align="center" | <br>
! width="500" align="center" | <br>
|-
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
| align="right" |

|}
<br/>
== Status ==
For more information on password storage for authentication, please visit the password storage cheatsheet here: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet .
==Introduction==

Most of today’s applications use login/password in order to authenticate. Users often use the same login/password for different kinds of applications. If the pair is stolen, everybody can access all the applications the user has access to.

Too often passwords are stored as clear text. Thus the password can be read directly by the database’s administrator, super users or SQL Injection attack etc. The backup media is also vulnerable.
In order to solve this problem, passwords must be stored encrypted. Two kinds of encryption are available:
* One way functions (SHA-256 SHA-1 MD5, ..;) also known as Hashing functions
* Reversible encryption functions (DES, AES, …).
However, the reversible property of encryption function is useless for credentials storing (cf. OWASP Guide v2.0.1) :

''Passwords are secrets. There is no reason to decrypt them under any circumstances. Helpdesk staff should be able to set new passwords (with an audit trail, obviously), not read back old passwords. Therefore, there is no reason to store passwords in a reversible form.''

==Definition of cryptographic Hashing function:==
A Hash function creates a fixed length small fingerprint (or message digest) from an unlimited input string.

hash(X) ->Y X is a infinite set and Y is a finite set.

A good cryptographic Hash function must have these properties:
* Preimage resistant : From the function output y it must impossible to compute the input x such that hash(x)=y.
* Second preimage resistant : from an input x1 it must impossible to compute another input x2 (different of x1) such that hash(x1)=hash(x2).
* Collision resistant : It must be difficult to find two inputs x1 and x2 (x1<>x2) such that hash(x1)=hash(x2).

'''Sample java code :'''
import java.security.MessageDigest;

public byte[] getHash(String password) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
byte[] input = digest.digest(password.getBytes("UTF-8"));
}

==Credential storage.==

If the password’s digest is stored in a database, an attacker should be unable to recover the password thanks to the preimage resistance. The only way to go past this would be a [[Brute force attack|brute force attack]], i.e. computing the hash of all possible passwords or a dictionary attack, i.e. computing all the often used password.

==Why add salt ? ==

If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to choosing to only storing the password’s hash:
* Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can find a password very quickly especially if the number of passwords the database is large.
* An attacker can use a list of precomputed hashes (http://en.wikipedia.org/wiki/Rainbow_table) to break passwords in seconds.

In order to solve these problems, a salt can be concatenated to the password before the digest operation.

A salt is a random number of a fixed length. This salt must be different for each stored entry. It must be stored as clear text next to the hashed password.

In this configuration, an attacker must handle a brute force attack on each individual password. The database is now birthday attack/rainbow crack resistant.

A 64-bit salt is recommended in RSA PKCS5 standard.

'''Sample java code :'''
import java.security.MessageDigest;

public byte[] getHash(String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-256");
digest.reset();
digest.update(salt);
return digest.digest(password.getBytes("UTF-8"));
}

==Hardening against the attacker's attack==

To slow down the computation it is recommended to iterate the hash operation n times. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don't really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.
A minimum of 1000 operations is recommended in RSA PKCS5 standard.

The stored password looks like this :
Hash(hash(hash(hash(……….hash(password||salt)))))))))))))))

To authenticate a user, the operation same as above must be performed, followed by a comparison of the two hashes.

The hash function you need to use depends of your security policy. SHA-256 or SHA-512 is recommended for long term storage.

'''Sample java code :'''
import java.security.*;

public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes("UTF-8"));
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

==Complete Java Sample==
In order to create the table needed by this application, call the method createTable().
It creates a TABLE called CREDENTIAL, with these fields :
* LOGIN VARCHAR (100) PRIMARY KEY
* PASSWORD VARCHAR (32)
* SALT VARCHAR (32)

In this database, the password and the salt are stored in Base64 representation.

The method ''authenticate'' is used in order to authenticate a user, the method ''createUser'' is used to create a new user.

package org.psafix.memopwd;

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.io.IOException;
import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;
import java.sql.*;
import java.util.Arrays;
import java.security.SecureRandom;

public class Owasp {
private final static int ITERATION_NUMBER = 1000;

public Owasp() {
}

/**
* Authenticates the user with a given login and password
* If password and/or login is null then always returns false.
* If the user does not exist in the database returns false.
* @param con Connection An open connection to a databse
* @param login String The login of the user
* @param password String The password of the user
* @return boolean Returns true if the user is authenticated, false otherwise
* @throws SQLException If the database is inconsistent or unavailable (
* (Two users with the same login, salt or digested password altered etc.)
* @throws NoSuchAlgorithmException If the algorithm SHA-1 is not supported by the JVM
*/
public boolean authenticate(Connection con, String login, String password)
throws SQLException, NoSuchAlgorithmException{
boolean authenticated=false;
PreparedStatement ps = null;
ResultSet rs = null;
try {
boolean userExist = true;
// INPUT VALIDATION
if (login==null||password==null){
// TIME RESISTANT ATTACK
// Computation time is equal to the time needed by a legitimate user
userExist = false;
login="";
password="";
}

ps = con.prepareStatement("SELECT PASSWORD, SALT FROM CREDENTIAL WHERE LOGIN = ?");
ps.setString(1, login);
rs = ps.executeQuery();
String digest, salt;
if (rs.next()) {
digest = rs.getString("PASSWORD");
salt = rs.getString("SALT");
// DATABASE VALIDATION
if (digest == null || salt == null) {
throw new SQLException("Database inconsistant Salt or Digested Password altered");
}
if (rs.next()) { // Should not append, because login is the primary key
throw new SQLException("Database inconsistent two CREDENTIALS with the same LOGIN");
}
} else { // TIME RESISTANT ATTACK (Even if the user does not exist the
// Computation time is equal to the time needed for a legitimate user
digest = "000000000000000000000000000=";
salt = "00000000000=";
userExist = false;
}

byte[] bDigest = base64ToByte(digest);
byte[] bSalt = base64ToByte(salt);

// Compute the new DIGEST
byte[] proposedDigest = getHash(ITERATION_NUMBER, password, bSalt);

return Arrays.equals(proposedDigest, bDigest) && userExist;
} catch (IOException ex){
throw new SQLException("Database inconsistant Salt or Digested Password altered");
}
finally{
close(rs);
close(ps);
}
}

/**
* Inserts a new user in the database
* @param con Connection An open connection to a databse
* @param login String The login of the user
* @param password String The password of the user
* @return boolean Returns true if the login and password are ok (not null and length(login)<=100
* @throws SQLException If the database is unavailable
* @throws NoSuchAlgorithmException If the algorithm SHA-1 or the SecureRandom is not supported by the JVM
*/
public boolean createUser(Connection con, String login, String password)
throws SQLException, NoSuchAlgorithmException
{
PreparedStatement ps = null;
try {
if (login!=null&&password!=null&&login.length()<=100){
// Uses a secure Random not a simple Random
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
// Salt generation 64 bits long
byte[] bSalt = new byte[8];
random.nextBytes(bSalt);
// Digest computation
byte[] bDigest = getHash(ITERATION_NUMBER,password,bSalt);
String sDigest = byteToBase64(bDigest);
String sSalt = byteToBase64(bSalt);

ps = con.prepareStatement("INSERT INTO CREDENTIAL (LOGIN, PASSWORD, SALT) VALUES (?,?,?)");
ps.setString(1,login);
ps.setString(2,sDigest);
ps.setString(3,sSalt);
ps.executeUpdate();
return true;
} else {
return false;
}
} finally {
close(ps);
}
}

/**
* From a password, a number of iterations and a salt,
* returns the corresponding digest
* @param iterationNb int The number of iterations of the algorithm
* @param password String The password to encrypt
* @param salt byte[] The salt
* @return byte[] The digested password
* @throws NoSuchAlgorithmException If the algorithm doesn't exist
*/
public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes("UTF-8"));
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

public void createTable(Connection con) throws SQLException{
Statement st = null;
try {
st = con.createStatement();
st.execute("CREATE TABLE CREDENTIAL (LOGIN VARCHAR(100) PRIMARY KEY, PASSWORD VARCHAR(32) NOT NULL, SALT VARCHAR(32) NOT NULL)");
} finally {
close(st);
}
}

/**
* Closes the current statement
* @param ps Statement
*/
public void close(Statement ps) {
if (ps!=null){
try {
ps.close();
} catch (SQLException ignore) {
}
}
}

/**
* Closes the current resultset
* @param ps Statement
*/
public void close(ResultSet rs) {
if (rs!=null){
try {
rs.close();
} catch (SQLException ignore) {
}
}
}

/**
* From a base 64 representation, returns the corresponding byte[]
* @param data String The base64 representation
* @return byte[]
* @throws IOException
*/
public static byte[] base64ToByte(String data) throws IOException {
BASE64Decoder decoder = new BASE64Decoder();
return decoder.decodeBuffer(data);
}

/**
* From a byte[] returns a base 64 representation
* @param data byte[]
* @return String
* @throws IOException
*/
public static String byteToBase64(byte[] data){
BASE64Encoder endecoder = new BASE64Encoder();
return endecoder.encode(data);
}

}

[[Category:OWASP Java Project]]

User talk:Markgordon

2012-10-31T17:37:12Z

Markgordon: Created page with "Greetings. I'm Mark Gordon, living in Edmonton, Alberta, Canada. I'm a software developer with a strong interest in infosec."

Greetings. I'm Mark Gordon, living in Edmonton, Alberta, Canada. I'm a software developer with a strong interest in infosec.

Edmonton

2007-04-05T01:25:19Z

Markgordon: Notice of the April 10, 2007 meeting

{{Chapter Template|chaptername=Edmonton|extra=The chapter leader is [mailto:robert.martin@shunda.com Robert Martin]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-edmonton|emailarchives=http://lists.owasp.org/pipermail/owasp-edmonton}}

== Local News ==

Our chapter's next meeting will take place Tuesday, April 10, 2007 at 6:00 PM at the Telus Plaza North Tower. Please meet us in the building's lobby before 6:00 so that we can escort you to the boardroom. The meeting will be over by 7:15. This [http://maps.google.ca/maps?f=q&hl=en&q=10025+Jasper+Ave+NW,+Edmonton,+AB&ie=UTF8&z=17&ll=53.54097,-113.491248&spn=0.004578,0.010493&t=h&om=1 map] guides you to Telus Plaza North.

The April topic will be "Using OWASP WSFuzzer for Web Service Penetration Testing", by Mark Gordon.

You don't need to bring an understanding of web services to the talk. After a 5-minute introduction to the basics of web services you will know plenty of new buzzwords, enough to impress your friends and befuddle your enemies. After the intro Mark will demonstrate several concrete examples of how [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project WSFuzzer] helps automate testing web services for vulnerabilities. If time permits we can also discuss other details of web services such as using Akamai for better performance and the acronym soup that is the world of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA].

Previous meetings covered:
* OWASP's Top Ten Project
* OWASP's WebGoat insecure web application
* Cross Site Scripting Attacks (Yegor's [http://www.owasp.org/images/5/5e/XssYegorJbanov.pdf slideshow])
* Pub Night(!); discussed strategies for secure use of personal web applications
* "Building Defensible Web App Architectures", by Jason Meltzer of Strange Research

Edmonton

2007-02-09T15:47:20Z

Markgordon: February, 2007 Meeting

Edmonton

2007-01-13T19:17:30Z

Markgordon: /* Local News */

Edmonton

2007-01-13T19:15:51Z

Markgordon: /* Local News */

Edmonton

2006-12-14T06:02:26Z

Markgordon: /* Local News */

File:XssYegorJbanov.pdf

2006-12-14T05:58:25Z

Markgordon: Yegor Jbanov's slideshow from his talk on Cross Site Scripting exploits, given to the OWASP Edmonton chapter, 2006.12.5.

Yegor Jbanov's slideshow from his talk on Cross Site Scripting exploits, given to the OWASP Edmonton chapter, 2006.12.5.

Edmonton

2006-12-06T04:46:04Z

Markgordon: /* Local News */

Edmonton

2006-11-30T15:59:14Z

Markgordon: /* Local News */

Edmonton

2006-10-27T01:42:03Z

Markgordon: /* Local News */

{{Chapter Template|chaptername=Edmonton|extra=The chapter leader is [mailto:robert.martin@shunda.com Robert Martin]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-edmonton|emailarchives=http://lists.owasp.org/pipermail/owasp-edmonton}}

== Local News ==

Our chapter's next meeting will be Dec 5. Yegor Jbanov will continue his overview of OWASP's WebGoat project. WebGoat is a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application. For example, in one of the lessons the user must use SQL injection to steal fake credit card numbers. The application is a realistic teaching environment, providing users with hints and code to further explain the lesson.

Yegor started his presentation at our October meeting. There was good discussion around the practical matters of how the security exploits work. Given the level of interest Yegor offered to present more exploits in the December meeting (Cross site scripting attacks and SQL Injection in particular!). Note: a knowledge of Java was ''not'' required to follow along.

The meeting will take place Tuesday, December 5, 2006 at 6:00 PM in the Telus Plaza North Tower. Please meet us in the building's lobby before 6:00 so that we can escort you to the boardroom. The meeting will be over by 7:15.

Here is a [http://maps.google.ca/maps?f=q&hl=en&q=10025+Jasper+Ave+NW,+Edmonton,+AB&ie=UTF8&z=17&ll=53.54097,-113.491248&spn=0.004578,0.010493&t=h&om=1 map]

Edmonton

2006-10-19T15:01:01Z

Markgordon: /* Local News */

Edmonton

2006-09-11T05:44:35Z

Markgordon: /* Local News */

Edmonton

2006-09-11T05:43:48Z

Markgordon: /* Local News */

Edmonton

2006-09-11T05:41:31Z

Markgordon: /* Local News */

Edmonton

2006-09-11T05:35:21Z

Markgordon: /* Local News */

Edmonton

2006-08-26T22:20:04Z

Markgordon: /* Local News */

Edmonton

2006-08-26T22:19:25Z

Markgordon: /* Local News */

Edmonton

2006-08-26T22:18:58Z

Markgordon: /* Local News */

Edmonton

2006-08-26T22:18:12Z

Markgordon: /* Local News */

Edmonton

2006-08-26T22:17:34Z

Markgordon: /* Local News */

Edmonton

2006-08-26T21:53:39Z

Markgordon: /* Local News */