OWASP - User contributions [en]

User:RoganDawes

2013-07-28T13:05:05Z

RoganDawes:

This page contains some information about Rogan Dawes

=== OWASP Projects ===

Rogan is the lead developer of the OWASP WebScarab, WebScarab-NG and OWASP Proxy projects.
He is also a contributor to the OWASP ESAPI project.
He has made substantial contributions to the OWASP WebGoat project.
Rogan can be contacted at rogan@dawes.za.net

Category:OWASP WebScarab Project

2013-03-11T21:16:48Z

RoganDawes: Update canonical source for WebScarab

{{OWASP Book|1416452}}
{{OWASP Breakers}}
= Main =
'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

You may also be interested in testing the [[OWASP WebScarab NG Project | Next Generation of WebScarab]].

==Screenshots==

Here's the main window of WebScarab. Check the [[WebScarab Getting Started]] guide for more screenshots of WebScarab in action.

[[Image:WebScarab after browsing.png]]

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP subscription page], and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

The canonical source repository for WebScarab is at [https://github.com/OWASP/OWASP-WebScarab GitHub]. A zip archive of the tip of tree can be downloaded [https://github.com/OWASP/OWASP-WebScarab/archive/master.zip here].

Historical Versions:

Alternatively, you can download older builds of WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge]. Then install them likewise:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: double-click the installer jar file [http://www.acsac.org/2007/downloads/t5-webscarab-instructions.pdf (complete installation instructions)])

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyzes a number of cookies to visually determine the degree of randomness and unpredictability. Note that this analysis is rather trivial, and does not do any serious checks, such as FIPS, etc.

* Scripted - operators can use BeanShell (or any other BSF supported language found on the classpath) to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server. '''NOTE''': This plugin is deprecated, and may be removed in the future. [http://www.soapui.org SOAPUI] is streets beyond anything that Webscarab can do, or will ever do, and is also a free tool.

* Extensions - automates checks for files that were mistakenly left in web server's root directory (e.g. .bak, ~, etc). Checks are performed for both, files and directories (e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Extensions for files and directories can be edited by user.

* XSS/CRLF - passive analysis plugin that searches for user-controlled data in HTTP response headers and body to identify potential CRLF injection (HTTP response splitting) and reflected cross-site scripting (XSS) vulnerabilities.

==Training Material==

Aung Khant (YGN Ethical Hacker Group, Myanmar) has created a series of WebScarab movies which can be found [http://yehg.net/lab/pr0js/training/webscarab.php here].

There are slides of the presentation "Uncovering Webscarab's Hidden Treasures", given at the OWASP EU Summit 2008, available [https://www.owasp.org/images/8/88/OWASP_EU_Summit_2008_WebScarab_treasures.ppt here].

==Future development==

Features will probably include:

* Combining the Search and Compare plugins, so that you can compare only specific responses

* Improving the fuzzer, adding ability to follow redirects, or to specify the number of threads to use. Also, adding the ability to define what is (or isn't) interesting in the fuzz results, and save only interesting conversations to the summary.

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes. He can be contacted at rogan AT dawes.za.net

= Project About =

{{:Projects/OWASP WebScarab Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|WebScarab Project]] [[Category:OWASP_Tool]] [[Category:OWASP_Download]] [[Category:OWASP Release Quality Tool]]

Category:OWASP Proxy

2011-06-21T06:59:49Z

RoganDawes: /* Project Contributors */ Remove employer

{{:Project Information:OWASP Proxy Project}}

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message header is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is represented as either a byte[] for the header, and an InputStream for the content, or a byte[] for the header, and a (possibly null) byte[] for the message content.

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding performed.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Using the OWASP Proxy==

===The Simplest Proxy===

About the simplest proxy that you can write is as follows:

RequestHandler requestHandler = new DefaultHttpRequestHandler();
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

A quick explanation of the classes referenced is warranted.

'''Server''' is a mostly trivial class that listens to an '''InetSocketAddress''', accepts connections and passes the accepted '''Socket''' on to implementations of the '''ConnectionHandler''' interface.

'''HttpProxyConnectionHandler''' is a '''ConnectionHandler''' implementation that implements an HTTP Proxy, reading HTTP requests from a client, passes those on to an '''HttpRequestHandler''' to fetch the '''Response''', then relays that '''Response''' back to the client.

'''DefaultHttpRequestHandler''' is just a simple implementation of the '''HttpRequestHandler''' interface, which makes use of the built-in custom HTTP Client to send the '''Request''' to the server, and obtain the '''Response'''.

Of course, it is not terribly useful. All it does is forward requests and responses, without doing anything with them.

===The Message Object Model===

Let's take a look at the message object model, before we try to do something more complex.

public interface MessageHeader {
byte[] getHeader();
String getStartLine() throws MessageFormatException;
NamedValue[] getHeaders() throws MessageFormatException;
String getHeader(String name) throws MessageFormatException;
}

public interface MutableMessageHeader {
void setHeader(byte[] header);
void setStartLine(String line) throws MessageFormatException;
void setHeaders(NamedValue[] headers) throws MessageFormatException;
void setHeader(String name, String value) throws MessageFormatException;
void addHeader(String name, String value) throws MessageFormatException;
String deleteHeader(String name) throws MessageFormatException;
}

This shows the interface for a MessageHeader, and a mutable MessageHeader. These are the foundations for the other message classes. Everything is represented in a single byte[]. If you want to create a message header that uses a plain CR as a line separator, go ahead and construct a byte[] that has the lines separated by CR's, and call setHeader(). Of course, the convenience methods are configured to expect CRLF, and so if you call any of those methods, you should expect to receive a MessageFormatException, and be prepared to parse the header manually.

===Message Content===

public interface StreamingMessage extends MutableMessageHeader {
InputStream getContent();
InputStream getDecodedContent() throws MessageFormatException;
void setContent(InputStream content);
void setDecodedContent(InputStream content) throws MessageFormatException;
}

public interface BufferedMessage extends MessageHeader {
byte[] getContent();
byte[] getDecodedContent() throws MessageFormatException;
}

public interface MutableBufferedMessage extends BufferedMessage, MutableMessageHeader {
void setContent(byte[] content);
void setDecodedContent(byte[] content) throws MessageFormatException;
}

The above interfaces represent the content of an HTTP message, either in a streaming or buffered state. Streaming messages are useful if you only really want to look at the message header, and not do anything with the message body, or if you can process the message body in a streaming fashion.

For example, you may want to compress a message transferred without gzip encoding. Update the message header to reflect the new encoding, wrap the content stream with a suitable GzipInputStream, and pass the message on to the next layer.

Of course, if you want to do something complex with the message body, you probably want to work with the buffered content. In that case, the BufferedMessage and MutableBufferedMessage interfaces are appropriate.

Note: There is a distinction between BufferedMessage and MutableBufferedMessage mainly as documentation indicating whether they should be modified or not in a particular method. See BufferedMessageInterceptor, for example.

===Requests and Responses===

This is what a Request header looks like. Again, there are convenience methods to obtain specific portions of the request, but underneath it all is that byte[] containing the entire header.

public interface RequestHeader extends MessageHeader {
InetSocketAddress getTarget();
boolean isSsl();
String getMethod() throws MessageFormatException;
String getResource() throws MessageFormatException;
String getVersion() throws MessageFormatException;
}

public interface MutableRequestHeader extends RequestHeader, MutableMessageHeader {
void setTarget(InetSocketAddress target);
void setSsl(boolean ssl);
void setMethod(String method) throws MessageFormatException;
void setResource(String resource) throws MessageFormatException;
void setVersion(String version) throws MessageFormatException;
}

Note that the target server and whether the message should be encrypted or not is external to the message header itself. In most cases, where no upstream proxy is involved, sending the request is as simple as opening a socket to the target InetSocketAddress, and calling write(message.getHeader()); Again, the minimum of parsing is performed, to allow for sending non-RFC compliant messages to a server.

There are similar interfaces for Responses, although they do not have an associated target.

==Intercepting HTTP Messages==

OWASP Proxy provides a BufferingHttpRequestHandler class which interacts with implementations of the BufferedMessageInterceptor interface to facilitate manipulation of the request and response.

This is what the BufferedMessageInterceptor interface looks like:

public interface BufferedMessageInterceptor {

enum Action { BUFFER, STREAM, IGNORE};

Action directRequest(MutableRequestHeader request);
void processRequest(MutableBufferedRequest request);
void requestContentSizeExceeded(BufferedRequest request, int size);
void requestStreamed(BufferedRequest request);

Action directResponse(RequestHeader request, MutableResponseHeader response)
void processResponse(RequestHeader request, MutableBufferedResponse response)
void responseContentSizeExceeded(RequestHeader request, ResponseHeader response, int size);
void responseStreamed(final RequestHeader request, BufferedResponse response);

}

Note: BufferedMessageInterceptor is actually an abstract class, to save implementation of methods that you have no interest in.

The first thing to do is decide which requests and responses your implementation is interested in. The "directRequest()" method is called first, with the RequestHeader as a parameter. Examine the request header to determine if the request is "interesting" or not. If you want the request content to be buffered, return Action.BUFFER. If you want the request content to be streamed to the server, return Action.STREAM. If you are not interested in any part of the request, you can return Action.IGNORE, and no further methods will be called for that particular Request/Response.

Note that the RequestHeader is actually Mutable, so if you are only interested in the header, you can make any changes you like in this method, and then return either Action.STREAM or Action.IGNORE, and forget about it.

The methods that will be invoked next depend on the Action that was returned.

If the Action was BUFFER, the processRequest(MutableBufferedRequest) method will be called, with the buffered request as a parameter. You can then modify it to suit, and when you return from this method, the buffered request will be sent to the server.

If the action was STREAM, the requestStreamed(BufferedRequest) method will be called. Note that this request is no longer mutable, as it is only invoked AFTER the entire request body has been streamed to the server.

Note: BufferingHttpRequestHandler takes a "max content size" parameter, to avoid buffering excessively large messages, and potentially running out of memory. If the limit is reached, the requestContentSizeExceeded(BufferedRequest, size) method is invoked, with the BufferedRequest containing the bytes buffered up to the size limit, and the size parameter containing the ultimate size of the message.

The same process is followed for the Response cycle. Determine if you are interested in the response, return a suitable Action, and handle the response in the appropriate methods thereafter.

==Putting an intercepting proxy together==

HttpRequestHandler requestHandler = new DefaultHttpRequestHandler();
BufferedMessageInterceptor interceptor = new BufferedMessageInterceptor() {
public Action directResponse(RequestHeader request, MutableResponseHeader response) {
return Action.BUFFER;
}

public void processResponse(RequestHeader request, MutableBufferedResponse response) {
try {
System.out.println(request.getResource() + " : " + response.getDecodedContent().length);
} catch (MessageFormatException mfe) {
mfe.printStackTrace();
}
}
};
int maxContentSize = 10240;
requestHandler = new BufferingHttpRequestHandler(requestHandler, interceptor, maxContentSize);
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

This constructs a very simple interceptor that just prints out the resource path, and the size of the decoded content.

==Can we add SSL intercept?==

Absolutely!

char[] password = "password".toCharArray();
HttpConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new DefaultServerContextSelector("server.p12", password, password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy); // true -> autodetect SSL
httpProxy.setConnectHandler(ssl);
Server proxy = new Server(listen, httpProxy);

This constructs an SSLConnectionHandler that automatically detects an incoming SSL connection based on the first few bytes read from the connection, negotiates an SSL Server connection with the client using the supplied certificate in the "server.p12" PKCS#12 file, then passes the decrypted connection on to the HttpProxyConnectionHandler. It also installs that same SSLConnectionHandler as the ConnectHandler of the HttpProxyConnectionHandler. i.e. when the HTTP Proxy receives a CONNECT request, after it is permitted, the raw byte stream is then passed back to the SSLConnectionHandler.

===How can we avoid browser warnings about untrusted connections?===

One problem with intercepting proxies that manifests when intercepting SSL connections is that traditionally the browser will present a warning to the user that the certificate used is invalid, and thus the connection is untrusted. In many cases, this is easily worked around by accepting the untrusted connection, and continuing, but for AJAX-y connections, there is no opportunity to accept that warning, and the site just ends up being non-functional.

OWASP Proxy includes a Sun JRE-specific class that uses Sun-internal classes to generate and sign a CA keypair and certificate, and then uses that to sign server-specific certificates. This means that if the CA certificate is imported into the browser, any further certificates signed by that CA certificate will automatically be trusted.

SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);

==Constructing a reverse proxy==

In essence, a proxy is just a server that already has a target. i.e. an InetSocketAddress that is automatically associated with all requests that it receives.

TargetedConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress target = new InetSocketAddress("example.com", 80);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Proxy proxy = new Proxy(listen, httpProxy, target);

===and adding SSL===

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy);
InetSocketAddress target = new InetSocketAddress("example.com", 80);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Proxy proxy = new Proxy(listen, ssl, target);

==SOCKS Proxies ROCK!==

While HTTP proxies are the most commonly encountered, SOCKS proxies are better in many ways. For one, SOCKS proxies are expected to simply relay data from client to server, and are not expected to understand the data being proxied. This means that the client doesn't have to add any proxy-specific message headers, and the behaviour of the client is exactly the same as if there was no proxy involved at all. The server should find a browser connecting through a SOCKS proxy indistinguishable from one that is connecting directly without any proxy at all.

This all means that if we want to be as transparent as possible in our interception, operating as a SOCKS proxy is the ideal approach. And it is trivial to do so:

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
ConnectionHandler socks = new SocksConnectionHandler(httpProxy, true); // true -> autodetect SOCKS
Server proxy = new Server(listen, socks);

==Putting it all together==

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy);
httpProxy.setConnectHandler(ssl);
ConnectionHandler socks = new SocksConnectionHandler(ssl, true);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Server proxy = new Server(listen, socks);

This constructs a SOCKS server, that will autodetect the SOCKS protocol, identify the target of the connection, autodetect an SSL connection, generate a suitable X.509 keypair and certificate, read HTTP messages from the client, relay them on to the targeted server, and return the responses to the client.

All in just a few lines of code! WOW!

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|Proxy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Alpha Quality Tool]]

Proyecto WebScarab OWASP

2011-06-21T06:58:11Z

RoganDawes: /* Contribuyentes del proyecto */ Remove employer

{{OWASP Book|1416452}}

'''Bienvenido al proyecto WebScarab'''

Webscarab es un marco de trabajo para analizar aplicaciónes web que se comunica usando los protocolos HTTP y HTTPS. Esta escrito en Java, por lo que es portable a muchas plataformas. WebScarac tiene muchos modos de operación, implementados por varios plugins. Su uso mas común es operar WebScarab como un proxy de intercepción, que permite al operador revisar y modificar las peticiones creadas por el navegador antes de que sean enviados al servidor, y para revisar y modificar respuestas enviadas por el servidor antes de que sean recividas por el navegador. Webscarab es capaz de interceptar comunicacion en HTTP y HTTPS. El operador puede tambien revisar las conversaciones (peticiones y respuestas) que hayan pasado por WebScarab.

Usted puede tambien estar interesado en probar la [[OWASP WebScarab NG Project | nueva generación de WebScarab]].

==Imagenes==

Aqui está la ventana principal de WebScarab. Vea la guía de [[WebScarab Getting Started | inicio en WebScarab]] para mas imagenes de WebScarab en acción.

[[Image:WebScarab after browsing.png]]

==Introducción==

No hay ningun gran boton rojo en WebScarab, es una herramienta diseñada principalmente para ser usada por personas que pueden escribir codigo por ellos mismos, or al menos tienen un muy buen conocimiento el protocolo HTTP. Si eso suena como a usted, Bienvenido! baje WebScarab, unase a la lista de distribución en la [http://lists.owasp.org/mailman/listinfo/owasp-webscarab pagina de suscripción de OWASP] y a disfrutar!. Puede leer este [[WebScarab Tutorial | pequeño tutorial ]] que explica la funcionalidad básica.

WebScarab está diseñado para ser una herramienta que cualquiera que necesite exponer la funcionalidad de una aplicación basada en HTTP(S), ya sea para permitir al desarrollador depurar problemas difíciles o permitir a un especialista en seguridad identificar vulnerabilidades mientras la aplicacion está siendo diseñada o implementada.

==Archivos==

Puede bajar WebScarab desde el [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 centro de código fuente de OWASP en Sourceforge]. Luego instalelo como sigue:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: de doble clic al archivo Jar de instalación

Puede encontrar un paquete de Mac OS X de la ultima version en la [http://research.corsaire.com/tools/ página de Corsaire].

Puede probar también [http://dawes.za.net/rogan/webscarab/WebScarab.jnlp la version de Java Web Start], la cual ha sido firmada por Rogan Dawes.

==Características==

Un marco de trabajo sin ninguna función que no valga la pena, por supuesto, WebScarab provee un numero de plugins, cuyo objetivo principal, por el momento, es agregar funcionalidad de seguridad. Estos plugins incluyen:

* Fragmentos - extraer los scripts y comentarios de las páginas HTML en el momento en que son vistar por el proxy y otros plugins.

* Proxy - Observa el trafico entre el navegador y el servidor Web. El proxy de WebScarab es capaz de observar tanto HTTP como trafico HTTPS cifrado al negociar una conexión SSL entre WebScarab y el navegador en ves de simplemente conectar el navegador a el sevidor y permitir que un flujo de datos cifrado pase por él. Varios plugins del proxy has sido tambien desarrollados para permitir al operador controlar las peticiones y respuestas que pasan por el proxy.

* Intercepción Manual - permite al usuario modificar peticiones y respuestas HTTP y HTTPS "al vuelo", antes de que ellas alcancen el servidor o el navegador.

* Beanshell - permite la ejecucion de operaciones arbitrarias complejas en las peticiones y respuestas. Cualquier cosas que pueda ser expresada en Java puede ser ejecutada.

* Revelar campos ocultos - algunas veces es mas fácil modificar un campo oculto en la página misma, mas que interceptar la peticion despues que ha sido enviada. Este plugin cambia todos los campos ocultos encontrados en las páginas HTML a campos de texto, haciéndolos visibles y editables.

* Simulador de ancho de banda - permite al usuario emular una red mas lenta, de manera que observe como se desempeña su sitio con es accedido, por ejemplo, desde un modem.

* Araña (Spider) - identifica nuevas URLs en el sitio objetivo y obtiene e contenido cuando se le indica.

* Peticiones manuales - permite editar y reenviar peticiones anteriores o la creación de peticiones nuevas completas.

* Análisis de identificadores de sesión - recolecta y analiza un número de cookies (y eventualmente parametros en el URL tambien) para determinar visualmente el grado de aleatoriedad y predecibilidad.

* Scripted - los operadores pueden usar BeanShell para escribir un script para create peticiones y obtenerlas del servidor. El script puede entonses realizar algunos análisis en las peticiones, con todo el poder del modelo de objetos de peticiones y respuestas de WebScarab para simplificar las cosas.

* Ofuscador de parámetros - realiza la sustitución automatizada de valores en los parametros que es probable que muestre una validación incompleta de parámetros. que lleve a vulnerabilidades como Secuencia de comandos en sitios cruzados(XSS) o inyección de SQL.

* Búsqueda - permite al usuario crear expresiones arbitrarias de BeanShell para identificar conversaciones que deben ser mostradas en la lista.

* Comparación - calcula la distacia de edición en el cuerpo de la respuesta de la conversación observada y una conversación predeterminada. La distacia de edicion es "el número de ediciones requeridad para transformar un documento en otro". Por razones de desempeño, las ediciones son calculadas usando testigos de palabras, mas que byte por byte.

* SOAP - hay un plucing que interpreta WSDL, y presenta las varias funciones y los parámetros requeridas, permitiendo que sean editadas antes de que sean enviadas a el servidor.

* Extensiones - automatiza las revisiones de archivos que fueron dejados por error en el directorio raiz del servidor (e.g. .bak, ~, etc). Las revisiones son realizadas en archivos y directorios (por ejemplo para /app/login.jsp se revisará /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Las extensiones para archivos y directorios pueden ser editados por el usuario.

* XSS/CRLF - este plugin de análisis pasivo busca datos controlados por el usuario en los encabezados y cuerpo de las respuestas HTTP para identificar posibles inyecciones CRLF (partición de respuesta HTTP) y vulnerabilidades de secuencia de comandos en sitios cruzados (XSS).

==Desarrollo futuro==

Features will probably include:

Las características probablemente incluirán:

* Un plugin de SOAP mejorado, mejorando el soporte para esquemas complejos y diferentes codificaciones

* Combinar los plugins de búsqueda y comparación, de manera que podamos comparar solo respuestas específicas.

==Estensibilidad==

Dado que es un marco de trabajo, WebScarab es extendible. Cada característica arriba es implementada como un plugin y puede ser removido o remplazado. Las nuevas características pueden ser fácilmente implementados también. El cielo es el límite! Si tiene una buena idea para un plugin, por favor déjenos saber sobre ello en la lista.

==Contribuyentes del proyecto==

el proyecto WebScarab es administrado por Rogan Dawes. Él puede ser contactado en rogan AT dawes.za.net

[[Category:OWASP Project|WebScarab Proyecto]]
[[Category:OWASP Tool|Herramienta OWASP]]
[[Category:OWASP Download|Archivos OWASP]]

Category:OWASP WebScarab Project

2011-06-21T06:56:43Z

RoganDawes: /* Project Contributors */ Remove employer

{{OWASP Book|1416452}}

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

You may also be interested in testing the [[OWASP WebScarab NG Project | Next Generation of WebScarab]].

==Screenshots==

Here's the main window of WebScarab. Check the [[WebScarab Getting Started]] guide for more screenshots of WebScarab in action.

[[Image:WebScarab after browsing.png]]

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP subscription page], and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

A ZIP containing an up to date build of the master branch of the [http://dawes.za.net/gitweb.cgi?p=webscarab.git webscarab git tree] can be found [http://dawes.za.net/rogan/webscarab/#current here]. This file is rebuilt whenever new commits are pushed to the repository, and will always be the most up to date build of WebScarab available.

A Mac OS X package of the latest version can usually be found on [http://research.corsaire.com/tools/ Corsaire's download page].

Historical Versions:

Alternatively, you can download older builds of WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge]. Then install them likewise:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: double-click the installer jar file [http://www.acsac.org/2007/downloads/t5-webscarab-instructions.pdf (complete installation instructions)])

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyzes a number of cookies to visually determine the degree of randomness and unpredictability. Note that this analysis is rather trivial, and does not do any serious checks, such as FIPS, etc.

* Scripted - operators can use BeanShell (or any other BSF supported language found on the classpath) to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server. '''NOTE''': This plugin is deprecated, and may be removed in the future. [http://www.soapui.org SOAPUI] is streets beyond anything that Webscarab can do, or will ever do, and is also a free tool.

* Extensions - automates checks for files that were mistakenly left in web server's root directory (e.g. .bak, ~, etc). Checks are performed for both, files and directories (e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Extensions for files and directories can be edited by user.

* XSS/CRLF - passive analysis plugin that searches for user-controlled data in HTTP response headers and body to identify potential CRLF injection (HTTP response splitting) and reflected cross-site scripting (XSS) vulnerabilities.

==Training Material==

Aung Khant (YGN Ethical Hacker Group, Myanmar) has created a series of WebScarab movies which can be found [http://yehg.net/lab/pr0js/training/webscarab.php here].

There are slides of the presentation "Uncovering Webscarab's Hidden Treasures", given at the OWASP EU Summit 2008, available [https://www.owasp.org/images/8/88/OWASP_EU_Summit_2008_WebScarab_treasures.ppt here].

==Future development==

Features will probably include:

* Combining the Search and Compare plugins, so that you can compare only specific responses

* Improving the fuzzer, adding ability to follow redirects, or to specify the number of threads to use. Also, adding the ability to define what is (or isn't) interesting in the fuzz results, and save only interesting conversations to the summary.

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|WebScarab Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP WebScarab Project

2010-08-27T16:44:19Z

RoganDawes: Correct link to current build. Remove link to webstart version

{{OWASP Book|1416452}}

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

You may also be interested in testing the [[OWASP WebScarab NG Project | Next Generation of WebScarab]].

==Screenshots==

Here's the main window of WebScarab. Check the [[WebScarab Getting Started]] guide for more screenshots of WebScarab in action.

[[Image:WebScarab after browsing.png]]

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP subscription page], and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

A ZIP containing an up to date build of the master branch of the [http://dawes.za.net/gitweb.cgi?p=webscarab.git webscarab git tree] can be found [http://dawes.za.net/rogan/webscarab/#current here]. This file is rebuilt whenever new commits are pushed to the repository, and will always be the most up to date build of WebScarab available.

A Mac OS X package of the latest version can usually be found on [http://research.corsaire.com/tools/ Corsaire's download page].

Historical Versions:

Alternatively, you can download older builds of WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge]. Then install them likewise:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: double-click the installer jar file [http://www.acsac.org/2007/downloads/t5-webscarab-instructions.pdf (complete installation instructions)])

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyzes a number of cookies to visually determine the degree of randomness and unpredictability. Note that this analysis is rather trivial, and does not do any serious checks, such as FIPS, etc.

* Scripted - operators can use BeanShell (or any other BSF supported language found on the classpath) to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server. '''NOTE''': This plugin is deprecated, and may be removed in the future. [http://www.soapui.org SOAPUI] is streets beyond anything that Webscarab can do, or will ever do, and is also a free tool.

* Extensions - automates checks for files that were mistakenly left in web server's root directory (e.g. .bak, ~, etc). Checks are performed for both, files and directories (e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Extensions for files and directories can be edited by user.

* XSS/CRLF - passive analysis plugin that searches for user-controlled data in HTTP response headers and body to identify potential CRLF injection (HTTP response splitting) and reflected cross-site scripting (XSS) vulnerabilities.

==Training Material==

Aung Khant (YGN Ethical Hacker Group, Myanmar) has created a series of WebScarab movies which can be found [http://yehg.net/lab/pr0js/training/webscarab.php here].

There are slides of the presentation "Uncovering Webscarab's Hidden Treasures", given at the OWASP EU Summit 2008, available [https://www.owasp.org/images/8/88/OWASP_EU_Summit_2008_WebScarab_treasures.ppt here].

==Future development==

Features will probably include:

* Combining the Search and Compare plugins, so that you can compare only specific responses

* Improving the fuzzer, adding ability to follow redirects, or to specify the number of threads to use. Also, adding the ability to define what is (or isn't) interesting in the fuzz results, and save only interesting conversations to the summary.

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|WebScarab Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP Proxy

2010-03-18T20:25:30Z

RoganDawes: Putting it all together

{{:Project Information:OWASP Proxy Project}}

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message header is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is represented as either a byte[] for the header, and an InputStream for the content, or a byte[] for the header, and a (possibly null) byte[] for the message content.

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding performed.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Using the OWASP Proxy==

===The Simplest Proxy===

About the simplest proxy that you can write is as follows:

RequestHandler requestHandler = new DefaultHttpRequestHandler();
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

A quick explanation of the classes referenced is warranted.

'''Server''' is a mostly trivial class that listens to an '''InetSocketAddress''', accepts connections and passes the accepted '''Socket''' on to implementations of the '''ConnectionHandler''' interface.

'''HttpProxyConnectionHandler''' is a '''ConnectionHandler''' implementation that implements an HTTP Proxy, reading HTTP requests from a client, passes those on to an '''HttpRequestHandler''' to fetch the '''Response''', then relays that '''Response''' back to the client.

'''DefaultHttpRequestHandler''' is just a simple implementation of the '''HttpRequestHandler''' interface, which makes use of the built-in custom HTTP Client to send the '''Request''' to the server, and obtain the '''Response'''.

Of course, it is not terribly useful. All it does is forward requests and responses, without doing anything with them.

===The Message Object Model===

Let's take a look at the message object model, before we try to do something more complex.

public interface MessageHeader {
byte[] getHeader();
String getStartLine() throws MessageFormatException;
NamedValue[] getHeaders() throws MessageFormatException;
String getHeader(String name) throws MessageFormatException;
}

public interface MutableMessageHeader {
void setHeader(byte[] header);
void setStartLine(String line) throws MessageFormatException;
void setHeaders(NamedValue[] headers) throws MessageFormatException;
void setHeader(String name, String value) throws MessageFormatException;
void addHeader(String name, String value) throws MessageFormatException;
String deleteHeader(String name) throws MessageFormatException;
}

This shows the interface for a MessageHeader, and a mutable MessageHeader. These are the foundations for the other message classes. Everything is represented in a single byte[]. If you want to create a message header that uses a plain CR as a line separator, go ahead and construct a byte[] that has the lines separated by CR's, and call setHeader(). Of course, the convenience methods are configured to expect CRLF, and so if you call any of those methods, you should expect to receive a MessageFormatException, and be prepared to parse the header manually.

===Message Content===

public interface StreamingMessage extends MutableMessageHeader {
InputStream getContent();
InputStream getDecodedContent() throws MessageFormatException;
void setContent(InputStream content);
void setDecodedContent(InputStream content) throws MessageFormatException;
}

public interface BufferedMessage extends MessageHeader {
byte[] getContent();
byte[] getDecodedContent() throws MessageFormatException;
}

public interface MutableBufferedMessage extends BufferedMessage, MutableMessageHeader {
void setContent(byte[] content);
void setDecodedContent(byte[] content) throws MessageFormatException;
}

The above interfaces represent the content of an HTTP message, either in a streaming or buffered state. Streaming messages are useful if you only really want to look at the message header, and not do anything with the message body, or if you can process the message body in a streaming fashion.

For example, you may want to compress a message transferred without gzip encoding. Update the message header to reflect the new encoding, wrap the content stream with a suitable GzipInputStream, and pass the message on to the next layer.

Of course, if you want to do something complex with the message body, you probably want to work with the buffered content. In that case, the BufferedMessage and MutableBufferedMessage interfaces are appropriate.

Note: There is a distinction between BufferedMessage and MutableBufferedMessage mainly as documentation indicating whether they should be modified or not in a particular method. See BufferedMessageInterceptor, for example.

===Requests and Responses===

This is what a Request header looks like. Again, there are convenience methods to obtain specific portions of the request, but underneath it all is that byte[] containing the entire header.

public interface RequestHeader extends MessageHeader {
InetSocketAddress getTarget();
boolean isSsl();
String getMethod() throws MessageFormatException;
String getResource() throws MessageFormatException;
String getVersion() throws MessageFormatException;
}

public interface MutableRequestHeader extends RequestHeader, MutableMessageHeader {
void setTarget(InetSocketAddress target);
void setSsl(boolean ssl);
void setMethod(String method) throws MessageFormatException;
void setResource(String resource) throws MessageFormatException;
void setVersion(String version) throws MessageFormatException;
}

Note that the target server and whether the message should be encrypted or not is external to the message header itself. In most cases, where no upstream proxy is involved, sending the request is as simple as opening a socket to the target InetSocketAddress, and calling write(message.getHeader()); Again, the minimum of parsing is performed, to allow for sending non-RFC compliant messages to a server.

There are similar interfaces for Responses, although they do not have an associated target.

==Intercepting HTTP Messages==

OWASP Proxy provides a BufferingHttpRequestHandler class which interacts with implementations of the BufferedMessageInterceptor interface to facilitate manipulation of the request and response.

This is what the BufferedMessageInterceptor interface looks like:

public interface BufferedMessageInterceptor {

enum Action { BUFFER, STREAM, IGNORE};

Action directRequest(MutableRequestHeader request);
void processRequest(MutableBufferedRequest request);
void requestContentSizeExceeded(BufferedRequest request, int size);
void requestStreamed(BufferedRequest request);

Action directResponse(RequestHeader request, MutableResponseHeader response)
void processResponse(RequestHeader request, MutableBufferedResponse response)
void responseContentSizeExceeded(RequestHeader request, ResponseHeader response, int size);
void responseStreamed(final RequestHeader request, BufferedResponse response);

}

Note: BufferedMessageInterceptor is actually an abstract class, to save implementation of methods that you have no interest in.

The first thing to do is decide which requests and responses your implementation is interested in. The "directRequest()" method is called first, with the RequestHeader as a parameter. Examine the request header to determine if the request is "interesting" or not. If you want the request content to be buffered, return Action.BUFFER. If you want the request content to be streamed to the server, return Action.STREAM. If you are not interested in any part of the request, you can return Action.IGNORE, and no further methods will be called for that particular Request/Response.

Note that the RequestHeader is actually Mutable, so if you are only interested in the header, you can make any changes you like in this method, and then return either Action.STREAM or Action.IGNORE, and forget about it.

The methods that will be invoked next depend on the Action that was returned.

If the Action was BUFFER, the processRequest(MutableBufferedRequest) method will be called, with the buffered request as a parameter. You can then modify it to suit, and when you return from this method, the buffered request will be sent to the server.

If the action was STREAM, the requestStreamed(BufferedRequest) method will be called. Note that this request is no longer mutable, as it is only invoked AFTER the entire request body has been streamed to the server.

Note: BufferingHttpRequestHandler takes a "max content size" parameter, to avoid buffering excessively large messages, and potentially running out of memory. If the limit is reached, the requestContentSizeExceeded(BufferedRequest, size) method is invoked, with the BufferedRequest containing the bytes buffered up to the size limit, and the size parameter containing the ultimate size of the message.

The same process is followed for the Response cycle. Determine if you are interested in the response, return a suitable Action, and handle the response in the appropriate methods thereafter.

==Putting an intercepting proxy together==

HttpRequestHandler requestHandler = new DefaultHttpRequestHandler();
BufferedMessageInterceptor interceptor = new BufferedMessageInterceptor() {
public Action directResponse(RequestHeader request, MutableResponseHeader response) {
return Action.BUFFER;
}

public void processResponse(RequestHeader request, MutableBufferedResponse response) {
try {
System.out.println(request.getResource() + " : “ + response.getDecodedContent().length);
} catch (MessageFormatException mfe) {
mfe.printStackTrace();
}
}
};
int maxContentSize = 10240;
requestHandler = new BufferingHttpRequestHandler(requestHandler, interceptor, maxContentSize);
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

This constructs a very simple interceptor that just prints out the resource path, and the size of the decoded content.

==Can we add SSL intercept?==

Absolutely!

char[] password = "password".toCharArray();
HttpConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new DefaultServerContextSelector(“server.p12", password, password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy); // true -> autodetect SSL
httpProxy.setConnectHandler(ssl);
Server proxy = new Server(listen, httpProxy);

This constructs an SSLConnectionHandler that automatically detects an incoming SSL connection based on the first few bytes read from the connection, negotiates an SSL Server connection with the client using the supplied certificate in the "server.p12" PKCS#12 file, then passes the decrypted connection on to the HttpProxyConnectionHandler. It also installs that same SSLConnectionHandler as the ConnectHandler of the HttpProxyConnectionHandler. i.e. when the HTTP Proxy receives a CONNECT request, after it is permitted, the raw byte stream is then passed back to the SSLConnectionHandler.

===How can we avoid browser warnings about untrusted connections?===

One problem with intercepting proxies that manifests when intercepting SSL connections is that traditionally the browser will present a warning to the user that the certificate used is invalid, and thus the connection is untrusted. In many cases, this is easily worked around by accepting the untrusted connection, and continuing, but for AJAX-y connections, there is no opportunity to accept that warning, and the site just ends up being non-functional.

OWASP Proxy includes a Sun JRE-specific class that uses Sun-internal classes to generate and sign a CA keypair and certificate, and then uses that to sign server-specific certificates. This means that if the CA certificate is imported into the browser, any further certificates signed by that CA certificate will automatically be trusted.

SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);

==Constructing a reverse proxy==

In essence, a proxy is just a server that already has a target. i.e. an InetSocketAddress that is automatically associated with all requests that it receives.

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress target = new InetSocketAddress(“example.com", 80);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Proxy proxy = new Proxy(listen, httpProxy, target);

===and adding SSL===

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy);
InetSocketAddress target = new InetSocketAddress(“example.com", 80);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Proxy proxy = new Proxy(listen, ssl, target);

==SOCKS Proxies ROCK!==

While HTTP proxies are the most commonly encountered, SOCKS proxies are better in many ways. For one, SOCKS proxies are expected to simply relay data from client to server, and are not expected to understand the data being proxied. This means that the client doesn't have to add any proxy-specific message headers, and the behaviour of the client is exactly the same as if there was no proxy involved at all. The server should find a browser connecting through a SOCKS proxy indistinguishable from one that is connecting directly without any proxy at all.

This all means that if we want to be as transparent as possible in our interception, operating as a SOCKS proxy is the ideal approach. And it is trivial to do so:

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
ConnectionHandler socks = new SocksConnectionHandler(httpProxy, true); // true -> autodetect SOCKS
Server proxy = new Server(listen, socks);

==Putting it all together==

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy);
httpProxy.setConnectHandler(ssl);
ConnectionHandler socks = new SocksConnectionHandler(ssl, true);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Server proxy = new Server(listen, socks);

This constructs a SOCKS server, that will autodetect the SOCKS protocol, identify the target of the connection, autodetect an SSL connection, generate a suitable X.509 keypair and certificate, read HTTP messages from the client, relay them on to the targeted server, and return the responses to the client.

All in just a few lines of code! WOW!

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|Proxy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Alpha Quality Tool]]

Category:OWASP Proxy

2010-03-18T20:24:23Z

RoganDawes: Put it all together

{{:Project Information:OWASP Proxy Project}}

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message header is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is represented as either a byte[] for the header, and an InputStream for the content, or a byte[] for the header, and a (possibly null) byte[] for the message content.

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding performed.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Using the OWASP Proxy==

===The Simplest Proxy===

About the simplest proxy that you can write is as follows:

RequestHandler requestHandler = new DefaultHttpRequestHandler();
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

A quick explanation of the classes referenced is warranted.

'''Server''' is a mostly trivial class that listens to an '''InetSocketAddress''', accepts connections and passes the accepted '''Socket''' on to implementations of the '''ConnectionHandler''' interface.

'''HttpProxyConnectionHandler''' is a '''ConnectionHandler''' implementation that implements an HTTP Proxy, reading HTTP requests from a client, passes those on to an '''HttpRequestHandler''' to fetch the '''Response''', then relays that '''Response''' back to the client.

'''DefaultHttpRequestHandler''' is just a simple implementation of the '''HttpRequestHandler''' interface, which makes use of the built-in custom HTTP Client to send the '''Request''' to the server, and obtain the '''Response'''.

Of course, it is not terribly useful. All it does is forward requests and responses, without doing anything with them.

===The Message Object Model===

Let's take a look at the message object model, before we try to do something more complex.

public interface MessageHeader {
byte[] getHeader();
String getStartLine() throws MessageFormatException;
NamedValue[] getHeaders() throws MessageFormatException;
String getHeader(String name) throws MessageFormatException;
}

public interface MutableMessageHeader {
void setHeader(byte[] header);
void setStartLine(String line) throws MessageFormatException;
void setHeaders(NamedValue[] headers) throws MessageFormatException;
void setHeader(String name, String value) throws MessageFormatException;
void addHeader(String name, String value) throws MessageFormatException;
String deleteHeader(String name) throws MessageFormatException;
}

This shows the interface for a MessageHeader, and a mutable MessageHeader. These are the foundations for the other message classes. Everything is represented in a single byte[]. If you want to create a message header that uses a plain CR as a line separator, go ahead and construct a byte[] that has the lines separated by CR's, and call setHeader(). Of course, the convenience methods are configured to expect CRLF, and so if you call any of those methods, you should expect to receive a MessageFormatException, and be prepared to parse the header manually.

===Message Content===

public interface StreamingMessage extends MutableMessageHeader {
InputStream getContent();
InputStream getDecodedContent() throws MessageFormatException;
void setContent(InputStream content);
void setDecodedContent(InputStream content) throws MessageFormatException;
}

public interface BufferedMessage extends MessageHeader {
byte[] getContent();
byte[] getDecodedContent() throws MessageFormatException;
}

public interface MutableBufferedMessage extends BufferedMessage, MutableMessageHeader {
void setContent(byte[] content);
void setDecodedContent(byte[] content) throws MessageFormatException;
}

The above interfaces represent the content of an HTTP message, either in a streaming or buffered state. Streaming messages are useful if you only really want to look at the message header, and not do anything with the message body, or if you can process the message body in a streaming fashion.

For example, you may want to compress a message transferred without gzip encoding. Update the message header to reflect the new encoding, wrap the content stream with a suitable GzipInputStream, and pass the message on to the next layer.

Of course, if you want to do something complex with the message body, you probably want to work with the buffered content. In that case, the BufferedMessage and MutableBufferedMessage interfaces are appropriate.

Note: There is a distinction between BufferedMessage and MutableBufferedMessage mainly as documentation indicating whether they should be modified or not in a particular method. See BufferedMessageInterceptor, for example.

===Requests and Responses===

This is what a Request header looks like. Again, there are convenience methods to obtain specific portions of the request, but underneath it all is that byte[] containing the entire header.

public interface RequestHeader extends MessageHeader {
InetSocketAddress getTarget();
boolean isSsl();
String getMethod() throws MessageFormatException;
String getResource() throws MessageFormatException;
String getVersion() throws MessageFormatException;
}

public interface MutableRequestHeader extends RequestHeader, MutableMessageHeader {
void setTarget(InetSocketAddress target);
void setSsl(boolean ssl);
void setMethod(String method) throws MessageFormatException;
void setResource(String resource) throws MessageFormatException;
void setVersion(String version) throws MessageFormatException;
}

Note that the target server and whether the message should be encrypted or not is external to the message header itself. In most cases, where no upstream proxy is involved, sending the request is as simple as opening a socket to the target InetSocketAddress, and calling write(message.getHeader()); Again, the minimum of parsing is performed, to allow for sending non-RFC compliant messages to a server.

There are similar interfaces for Responses, although they do not have an associated target.

==Intercepting HTTP Messages==

OWASP Proxy provides a BufferingHttpRequestHandler class which interacts with implementations of the BufferedMessageInterceptor interface to facilitate manipulation of the request and response.

This is what the BufferedMessageInterceptor interface looks like:

public interface BufferedMessageInterceptor {

enum Action { BUFFER, STREAM, IGNORE};

Action directRequest(MutableRequestHeader request);
void processRequest(MutableBufferedRequest request);
void requestContentSizeExceeded(BufferedRequest request, int size);
void requestStreamed(BufferedRequest request);

Action directResponse(RequestHeader request, MutableResponseHeader response)
void processResponse(RequestHeader request, MutableBufferedResponse response)
void responseContentSizeExceeded(RequestHeader request, ResponseHeader response, int size);
void responseStreamed(final RequestHeader request, BufferedResponse response);

}

Note: BufferedMessageInterceptor is actually an abstract class, to save implementation of methods that you have no interest in.

The first thing to do is decide which requests and responses your implementation is interested in. The "directRequest()" method is called first, with the RequestHeader as a parameter. Examine the request header to determine if the request is "interesting" or not. If you want the request content to be buffered, return Action.BUFFER. If you want the request content to be streamed to the server, return Action.STREAM. If you are not interested in any part of the request, you can return Action.IGNORE, and no further methods will be called for that particular Request/Response.

Note that the RequestHeader is actually Mutable, so if you are only interested in the header, you can make any changes you like in this method, and then return either Action.STREAM or Action.IGNORE, and forget about it.

The methods that will be invoked next depend on the Action that was returned.

If the Action was BUFFER, the processRequest(MutableBufferedRequest) method will be called, with the buffered request as a parameter. You can then modify it to suit, and when you return from this method, the buffered request will be sent to the server.

If the action was STREAM, the requestStreamed(BufferedRequest) method will be called. Note that this request is no longer mutable, as it is only invoked AFTER the entire request body has been streamed to the server.

Note: BufferingHttpRequestHandler takes a "max content size" parameter, to avoid buffering excessively large messages, and potentially running out of memory. If the limit is reached, the requestContentSizeExceeded(BufferedRequest, size) method is invoked, with the BufferedRequest containing the bytes buffered up to the size limit, and the size parameter containing the ultimate size of the message.

The same process is followed for the Response cycle. Determine if you are interested in the response, return a suitable Action, and handle the response in the appropriate methods thereafter.

==Putting an intercepting proxy together==

HttpRequestHandler requestHandler = new DefaultHttpRequestHandler();
BufferedMessageInterceptor interceptor = new BufferedMessageInterceptor() {
public Action directResponse(RequestHeader request, MutableResponseHeader response) {
return Action.BUFFER;
}

public void processResponse(RequestHeader request, MutableBufferedResponse response) {
try {
System.out.println(request.getResource() + " : “ + response.getDecodedContent().length);
} catch (MessageFormatException mfe) {
mfe.printStackTrace();
}
}
};
int maxContentSize = 10240;
requestHandler = new BufferingHttpRequestHandler(requestHandler, interceptor, maxContentSize);
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

This constructs a very simple interceptor that just prints out the resource path, and the size of the decoded content.

==Can we add SSL intercept?==

Absolutely!

char[] password = "password".toCharArray();
HttpConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new DefaultServerContextSelector(“server.p12", password, password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy); // true -> autodetect SSL
httpProxy.setConnectHandler(ssl);
Server proxy = new Server(listen, httpProxy);

This constructs an SSLConnectionHandler that automatically detects an incoming SSL connection based on the first few bytes read from the connection, negotiates an SSL Server connection with the client using the supplied certificate in the "server.p12" PKCS#12 file, then passes the decrypted connection on to the HttpProxyConnectionHandler. It also installs that same SSLConnectionHandler as the ConnectHandler of the HttpProxyConnectionHandler. i.e. when the HTTP Proxy receives a CONNECT request, after it is permitted, the raw byte stream is then passed back to the SSLConnectionHandler.

===How can we avoid browser warnings about untrusted connections?===

One problem with intercepting proxies that manifests when intercepting SSL connections is that traditionally the browser will present a warning to the user that the certificate used is invalid, and thus the connection is untrusted. In many cases, this is easily worked around by accepting the untrusted connection, and continuing, but for AJAX-y connections, there is no opportunity to accept that warning, and the site just ends up being non-functional.

OWASP Proxy includes a Sun JRE-specific class that uses Sun-internal classes to generate and sign a CA keypair and certificate, and then uses that to sign server-specific certificates. This means that if the CA certificate is imported into the browser, any further certificates signed by that CA certificate will automatically be trusted.

SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);

==Constructing a reverse proxy==

In essence, a proxy is just a server that already has a target. i.e. an InetSocketAddress that is automatically associated with all requests that it receives.

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress target = new InetSocketAddress(“example.com", 80);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Proxy proxy = new Proxy(listen, httpProxy, target);

===and adding SSL===

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy);
InetSocketAddress target = new InetSocketAddress(“example.com", 80);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Proxy proxy = new Proxy(listen, ssl, target);

==SOCKS Proxies ROCK!==

While HTTP proxies are the most commonly encountered, SOCKS proxies are better in many ways. For one, SOCKS proxies are expected to simply relay data from client to server, and are not expected to understand the data being proxied. This means that the client doesn't have to add any proxy-specific message headers, and the behaviour of the client is exactly the same as if there was no proxy involved at all. The server should find a browser connecting through a SOCKS proxy indistinguishable from one that is connecting directly without any proxy at all.

This all means that if we want to be as transparent as possible in our interception, operating as a SOCKS proxy is the ideal approach. And it is trivial to do so:

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
ConnectionHandler socks = new SocksConnectionHandler(httpProxy, true); // true -> autodetect SOCKS
Server proxy = new Server(listen, socks);

Of course, adding SSL into the mix again is also trivial:

ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy);
httpProxy.setConnectHandler(ssl);
ConnectionHandler socks = new SocksConnectionHandler(ssl, true);
InetSocketAddress listen = new InetSocketAddress("localhost", 80);
Server proxy = new Server(listen, socks);

This constructs a SOCKS server, that will autodetect the SOCKS protocol, identify the target of the connection, autodetect an SSL connection, generate a suitable X.509 keypair and certificate, read HTTP messages from the client, relay them on to the targeted server, and return the responses to the client.

All in just a few lines of code! WOW!

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|Proxy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Alpha Quality Tool]]

Category:OWASP Proxy

2010-03-18T20:07:39Z

RoganDawes: Add some highlights

{{:Project Information:OWASP Proxy Project}}

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message header is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is represented as either a byte[] for the header, and an InputStream for the content, or a byte[] for the header, and a (possibly null) byte[] for the message content.

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding performed.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Using the OWASP Proxy==

===The Simplest Proxy===

About the simplest proxy that you can write is as follows:

RequestHandler requestHandler = new DefaultHttpRequestHandler();
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

A quick explanation of the classes referenced is warranted.

'''Server''' is a mostly trivial class that listens to an '''InetSocketAddress''', accepts connections and passes the accepted '''Socket''' on to implementations of the '''ConnectionHandler''' interface.

'''HttpProxyConnectionHandler''' is a '''ConnectionHandler''' implementation that implements an HTTP Proxy, reading HTTP requests from a client, passes those on to an '''HttpRequestHandler''' to fetch the '''Response''', then relays that '''Response''' back to the client.

'''DefaultHttpRequestHandler''' is just a simple implementation of the '''HttpRequestHandler''' interface, which makes use of the built-in custom HTTP Client to send the '''Request''' to the server, and obtain the '''Response'''.

Of course, it is not terribly useful. All it does is forward requests and responses, without doing anything with them.

===The Message Object Model===

Let's take a look at the message object model, before we try to do something more complex.

public interface MessageHeader {
byte[] getHeader();
String getStartLine() throws MessageFormatException;
NamedValue[] getHeaders() throws MessageFormatException;
String getHeader(String name) throws MessageFormatException;
}

public interface MutableMessageHeader {
void setHeader(byte[] header);
void setStartLine(String line) throws MessageFormatException;
void setHeaders(NamedValue[] headers) throws MessageFormatException;
void setHeader(String name, String value) throws MessageFormatException;
void addHeader(String name, String value) throws MessageFormatException;
String deleteHeader(String name) throws MessageFormatException;
}

This shows the interface for a MessageHeader, and a mutable MessageHeader. These are the foundations for the other message classes. Everything is represented in a single byte[]. If you want to create a message header that uses a plain CR as a line separator, go ahead and construct a byte[] that has the lines separated by CR's, and call setHeader(). Of course, the convenience methods are configured to expect CRLF, and so if you call any of those methods, you should expect to receive a MessageFormatException, and be prepared to parse the header manually.

===Message Content===

public interface StreamingMessage extends MutableMessageHeader {
InputStream getContent();
InputStream getDecodedContent() throws MessageFormatException;
void setContent(InputStream content);
void setDecodedContent(InputStream content) throws MessageFormatException;
}

public interface BufferedMessage extends MessageHeader {
byte[] getContent();
byte[] getDecodedContent() throws MessageFormatException;
}

public interface MutableBufferedMessage extends BufferedMessage, MutableMessageHeader {
void setContent(byte[] content);
void setDecodedContent(byte[] content) throws MessageFormatException;
}

The above interfaces represent the content of an HTTP message, either in a streaming or buffered state. Streaming messages are useful if you only really want to look at the message header, and not do anything with the message body, or if you can process the message body in a streaming fashion.

For example, you may want to compress a message transferred without gzip encoding. Update the message header to reflect the new encoding, wrap the content stream with a suitable GzipInputStream, and pass the message on to the next layer.

Of course, if you want to do something complex with the message body, you probably want to work with the buffered content. In that case, the BufferedMessage and MutableBufferedMessage interfaces are appropriate.

Note: There is a distinction between BufferedMessage and MutableBufferedMessage mainly as documentation indicating whether they should be modified or not in a particular method. See BufferedMessageInterceptor, for example.

===Requests and Responses===

This is what a Request header looks like. Again, there are convenience methods to obtain specific portions of the request, but underneath it all is that byte[] containing the entire header.

public interface RequestHeader extends MessageHeader {
InetSocketAddress getTarget();
boolean isSsl();
String getMethod() throws MessageFormatException;
String getResource() throws MessageFormatException;
String getVersion() throws MessageFormatException;
}

public interface MutableRequestHeader extends RequestHeader, MutableMessageHeader {
void setTarget(InetSocketAddress target);
void setSsl(boolean ssl);
void setMethod(String method) throws MessageFormatException;
void setResource(String resource) throws MessageFormatException;
void setVersion(String version) throws MessageFormatException;
}

Note that the target server and whether the message should be encrypted or not is external to the message header itself. In most cases, where no upstream proxy is involved, sending the request is as simple as opening a socket to the target InetSocketAddress, and calling write(message.getHeader()); Again, the minimum of parsing is performed, to allow for sending non-RFC compliant messages to a server.

There are similar interfaces for Responses, although they do not have an associated target.

==Intercepting HTTP Messages==

OWASP Proxy provides a BufferingHttpRequestHandler class which interacts with implementations of the BufferedMessageInterceptor interface to facilitate manipulation of the request and response.

This is what the BufferedMessageInterceptor interface looks like:

public interface BufferedMessageInterceptor {

enum Action { BUFFER, STREAM, IGNORE};

Action directRequest(MutableRequestHeader request);
void processRequest(MutableBufferedRequest request);
void requestContentSizeExceeded(BufferedRequest request, int size);
void requestStreamed(BufferedRequest request);

Action directResponse(RequestHeader request, MutableResponseHeader response)
void processResponse(RequestHeader request, MutableBufferedResponse response)
void responseContentSizeExceeded(RequestHeader request, ResponseHeader response, int size);
void responseStreamed(final RequestHeader request, BufferedResponse response);

}

Note: BufferedMessageInterceptor is actually an abstract class, to save implementation of methods that you have no interest in.

The first thing to do is decide which requests and responses your implementation is interested in. The "directRequest()" method is called first, with the RequestHeader as a parameter. Examine the request header to determine if the request is "interesting" or not. If you want the request content to be buffered, return Action.BUFFER. If you want the request content to be streamed to the server, return Action.STREAM. If you are not interested in any part of the request, you can return Action.IGNORE, and no further methods will be called for that particular Request/Response.

Note that the RequestHeader is actually Mutable, so if you are only interested in the header, you can make any changes you like in this method, and then return either Action.STREAM or Action.IGNORE, and forget about it.

The methods that will be invoked next depend on the Action that was returned.

If the Action was BUFFER, the processRequest(MutableBufferedRequest) method will be called, with the buffered request as a parameter. You can then modify it to suit, and when you return from this method, the buffered request will be sent to the server.

If the action was STREAM, the requestStreamed(BufferedRequest) method will be called. Note that this request is no longer mutable, as it is only invoked AFTER the entire request body has been streamed to the server.

Note: BufferingHttpRequestHandler takes a "max content size" parameter, to avoid buffering excessively large messages, and potentially running out of memory. If the limit is reached, the requestContentSizeExceeded(BufferedRequest, size) method is invoked, with the BufferedRequest containing the bytes buffered up to the size limit, and the size parameter containing the ultimate size of the message.

The same process is followed for the Response cycle. Determine if you are interested in the response, return a suitable Action, and handle the response in the appropriate methods thereafter.

==Putting an intercepting proxy together==

HttpRequestHandler requestHandler = new DefaultHttpRequestHandler();
BufferedMessageInterceptor interceptor = new BufferedMessageInterceptor() {
public Action directResponse(RequestHeader request, MutableResponseHeader response) {
return Action.BUFFER;
}

public void processResponse(RequestHeader request, MutableBufferedResponse response) {
try {
System.out.println(request.getResource() + " : “ + response.getDecodedContent().length);
} catch (MessageFormatException mfe) {
mfe.printStackTrace();
}
}
};
int maxContentSize = 10240;
requestHandler = new BufferingHttpRequestHandler(requestHandler, interceptor, maxContentSize);
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

This constructs a very simple interceptor that just prints out the resource path, and the size of the decoded content.

==Can we add SSL intercept?==

Absolutely!

char[] password = "password".toCharArray();
HttpConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new DefaultServerContextSelector(“server.p12", password, password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy); // true -> autodetect SSL
httpProxy.setConnectHandler(ssl);
Server proxy = new Server(listen, httpProxy);

This constructs an SSLConnectionHandler that automatically detects an incoming SSL connection based on the first few bytes read from the connection, negotiates an SSL Server connection with the client using the supplied certificate in the "server.p12" PKCS#12 file, then passes the decrypted connection on to the HttpProxyConnectionHandler. It also installs that same SSLConnectionHandler as the ConnectHandler of the HttpProxyConnectionHandler. i.e. when the HTTP Proxy receives a CONNECT request, after it is permitted, the raw byte stream is then passed back to the SSLConnectionHandler.

===How can we avoid browser warnings about untrusted connections?===

One problem with intercepting proxies that manifests when intercepting SSL connections is that traditionally the browser will present a warning to the user that the certificate used is invalid, and thus the connection is untrusted. In many cases, this is easily worked around by accepting the untrusted connection, and continuing, but for AJAX-y connections, there is no opportunity to accept that warning, and the site just ends up being non-functional.

OWASP Proxy includes a Sun JRE-specific class that uses Sun-internal classes to generate and sign a CA keypair and certificate, and then uses that to sign server-specific certificates. This means that if the CA certificate is imported into the browser, any further certificates signed by that CA certificate will automatically be trusted.

SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|Proxy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Alpha Quality Tool]]

Category:OWASP Proxy

2010-03-18T20:04:59Z

RoganDawes: Explain the classes involved

{{:Project Information:OWASP Proxy Project}}

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message header is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is represented as either a byte[] for the header, and an InputStream for the content, or a byte[] for the header, and a (possibly null) byte[] for the message content.

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding performed.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Using the OWASP Proxy==

===The Simplest Proxy===

About the simplest proxy that you can write is as follows:

RequestHandler requestHandler = new DefaultHttpRequestHandler();
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

A quick explanation of the classes referenced is warranted.

Server is a mostly trivial class that listens to an InetSocketAddress, accepts connections and passes the accepted Socket on to implementations of the ConnectionHandler interface.

HttpProxyConnectionHandler is a ConnectionHandler implementation that implements an HTTP Proxy, reading HTTP requests from a client, passes those on to an HttpRequestHandler to fetch the Response, then relays that response back to the client.

DefaultHttpRequestHandler is just a simple implementation of the HttpRequestHandler interface, which makes use of the built-in custom HTTP Client to send the Request to the server, and obtain the Response.

Of course, it is not terribly useful. All it does is forward requests and responses, without doing anything with them.

===The Message Object Model===

Let's take a look at the message object model, before we try to do something more complex.

public interface MessageHeader {
byte[] getHeader();
String getStartLine() throws MessageFormatException;
NamedValue[] getHeaders() throws MessageFormatException;
String getHeader(String name) throws MessageFormatException;
}

public interface MutableMessageHeader {
void setHeader(byte[] header);
void setStartLine(String line) throws MessageFormatException;
void setHeaders(NamedValue[] headers) throws MessageFormatException;
void setHeader(String name, String value) throws MessageFormatException;
void addHeader(String name, String value) throws MessageFormatException;
String deleteHeader(String name) throws MessageFormatException;
}

This shows the interface for a MessageHeader, and a mutable MessageHeader. These are the foundations for the other message classes. Everything is represented in a single byte[]. If you want to create a message header that uses a plain CR as a line separator, go ahead and construct a byte[] that has the lines separated by CR's, and call setHeader(). Of course, the convenience methods are configured to expect CRLF, and so if you call any of those methods, you should expect to receive a MessageFormatException, and be prepared to parse the header manually.

===Message Content===

public interface StreamingMessage extends MutableMessageHeader {
InputStream getContent();
InputStream getDecodedContent() throws MessageFormatException;
void setContent(InputStream content);
void setDecodedContent(InputStream content) throws MessageFormatException;
}

public interface BufferedMessage extends MessageHeader {
byte[] getContent();
byte[] getDecodedContent() throws MessageFormatException;
}

public interface MutableBufferedMessage extends BufferedMessage, MutableMessageHeader {
void setContent(byte[] content);
void setDecodedContent(byte[] content) throws MessageFormatException;
}

The above interfaces represent the content of an HTTP message, either in a streaming or buffered state. Streaming messages are useful if you only really want to look at the message header, and not do anything with the message body, or if you can process the message body in a streaming fashion.

For example, you may want to compress a message transferred without gzip encoding. Update the message header to reflect the new encoding, wrap the content stream with a suitable GzipInputStream, and pass the message on to the next layer.

Of course, if you want to do something complex with the message body, you probably want to work with the buffered content. In that case, the BufferedMessage and MutableBufferedMessage interfaces are appropriate.

Note: There is a distinction between BufferedMessage and MutableBufferedMessage mainly as documentation indicating whether they should be modified or not in a particular method. See BufferedMessageInterceptor, for example.

===Requests and Responses===

This is what a Request header looks like. Again, there are convenience methods to obtain specific portions of the request, but underneath it all is that byte[] containing the entire header.

public interface RequestHeader extends MessageHeader {
InetSocketAddress getTarget();
boolean isSsl();
String getMethod() throws MessageFormatException;
String getResource() throws MessageFormatException;
String getVersion() throws MessageFormatException;
}

public interface MutableRequestHeader extends RequestHeader, MutableMessageHeader {
void setTarget(InetSocketAddress target);
void setSsl(boolean ssl);
void setMethod(String method) throws MessageFormatException;
void setResource(String resource) throws MessageFormatException;
void setVersion(String version) throws MessageFormatException;
}

Note that the target server and whether the message should be encrypted or not is external to the message header itself. In most cases, where no upstream proxy is involved, sending the request is as simple as opening a socket to the target InetSocketAddress, and calling write(message.getHeader()); Again, the minimum of parsing is performed, to allow for sending non-RFC compliant messages to a server.

There are similar interfaces for Responses, although they do not have an associated target.

==Intercepting HTTP Messages==

OWASP Proxy provides a BufferingHttpRequestHandler class which interacts with implementations of the BufferedMessageInterceptor interface to facilitate manipulation of the request and response.

This is what the BufferedMessageInterceptor interface looks like:

public interface BufferedMessageInterceptor {

enum Action { BUFFER, STREAM, IGNORE};

Action directRequest(MutableRequestHeader request);
void processRequest(MutableBufferedRequest request);
void requestContentSizeExceeded(BufferedRequest request, int size);
void requestStreamed(BufferedRequest request);

Action directResponse(RequestHeader request, MutableResponseHeader response)
void processResponse(RequestHeader request, MutableBufferedResponse response)
void responseContentSizeExceeded(RequestHeader request, ResponseHeader response, int size);
void responseStreamed(final RequestHeader request, BufferedResponse response);

}

Note: BufferedMessageInterceptor is actually an abstract class, to save implementation of methods that you have no interest in.

The first thing to do is decide which requests and responses your implementation is interested in. The "directRequest()" method is called first, with the RequestHeader as a parameter. Examine the request header to determine if the request is "interesting" or not. If you want the request content to be buffered, return Action.BUFFER. If you want the request content to be streamed to the server, return Action.STREAM. If you are not interested in any part of the request, you can return Action.IGNORE, and no further methods will be called for that particular Request/Response.

Note that the RequestHeader is actually Mutable, so if you are only interested in the header, you can make any changes you like in this method, and then return either Action.STREAM or Action.IGNORE, and forget about it.

The methods that will be invoked next depend on the Action that was returned.

If the Action was BUFFER, the processRequest(MutableBufferedRequest) method will be called, with the buffered request as a parameter. You can then modify it to suit, and when you return from this method, the buffered request will be sent to the server.

If the action was STREAM, the requestStreamed(BufferedRequest) method will be called. Note that this request is no longer mutable, as it is only invoked AFTER the entire request body has been streamed to the server.

Note: BufferingHttpRequestHandler takes a "max content size" parameter, to avoid buffering excessively large messages, and potentially running out of memory. If the limit is reached, the requestContentSizeExceeded(BufferedRequest, size) method is invoked, with the BufferedRequest containing the bytes buffered up to the size limit, and the size parameter containing the ultimate size of the message.

The same process is followed for the Response cycle. Determine if you are interested in the response, return a suitable Action, and handle the response in the appropriate methods thereafter.

==Putting an intercepting proxy together==

HttpRequestHandler requestHandler = new DefaultHttpRequestHandler();
BufferedMessageInterceptor interceptor = new BufferedMessageInterceptor() {
public Action directResponse(RequestHeader request, MutableResponseHeader response) {
return Action.BUFFER;
}

public void processResponse(RequestHeader request, MutableBufferedResponse response) {
try {
System.out.println(request.getResource() + " : “ + response.getDecodedContent().length);
} catch (MessageFormatException mfe) {
mfe.printStackTrace();
}
}
};
int maxContentSize = 10240;
requestHandler = new BufferingHttpRequestHandler(requestHandler, interceptor, maxContentSize);
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

This constructs a very simple interceptor that just prints out the resource path, and the size of the decoded content.

==Can we add SSL intercept?==

Absolutely!

char[] password = "password".toCharArray();
HttpConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new DefaultServerContextSelector(“server.p12", password, password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy); // true -> autodetect SSL
httpProxy.setConnectHandler(ssl);
Server proxy = new Server(listen, httpProxy);

This constructs an SSLConnectionHandler that automatically detects an incoming SSL connection based on the first few bytes read from the connection, negotiates an SSL Server connection with the client using the supplied certificate in the "server.p12" PKCS#12 file, then passes the decrypted connection on to the HttpProxyConnectionHandler. It also installs that same SSLConnectionHandler as the ConnectHandler of the HttpProxyConnectionHandler. i.e. when the HTTP Proxy receives a CONNECT request, after it is permitted, the raw byte stream is then passed back to the SSLConnectionHandler.

===How can we avoid browser warnings about untrusted connections?===

One problem with intercepting proxies that manifests when intercepting SSL connections is that traditionally the browser will present a warning to the user that the certificate used is invalid, and thus the connection is untrusted. In many cases, this is easily worked around by accepting the untrusted connection, and continuing, but for AJAX-y connections, there is no opportunity to accept that warning, and the site just ends up being non-functional.

OWASP Proxy includes a Sun JRE-specific class that uses Sun-internal classes to generate and sign a CA keypair and certificate, and then uses that to sign server-specific certificates. This means that if the CA certificate is imported into the browser, any further certificates signed by that CA certificate will automatically be trusted.

SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|Proxy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Alpha Quality Tool]]

Category:OWASP Proxy

2010-03-18T19:59:44Z

RoganDawes: Adding SSL to a proxy

{{:Project Information:OWASP Proxy Project}}

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message header is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is represented as either a byte[] for the header, and an InputStream for the content, or a byte[] for the header, and a (possibly null) byte[] for the message content.

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding performed.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Using the OWASP Proxy==

===The Simplest Proxy===

About the simplest proxy that you can write is as follows:

RequestHandler requestHandler = new DefaultHttpRequestHandler();
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

Of course, it is not terribly useful. All it does is forward requests and responses.

===The Message Object Model===

Let's take a look at the message object model, before we try to do something more complex.

public interface MessageHeader {
byte[] getHeader();
String getStartLine() throws MessageFormatException;
NamedValue[] getHeaders() throws MessageFormatException;
String getHeader(String name) throws MessageFormatException;
}

public interface MutableMessageHeader {
void setHeader(byte[] header);
void setStartLine(String line) throws MessageFormatException;
void setHeaders(NamedValue[] headers) throws MessageFormatException;
void setHeader(String name, String value) throws MessageFormatException;
void addHeader(String name, String value) throws MessageFormatException;
String deleteHeader(String name) throws MessageFormatException;
}

This shows the interface for a MessageHeader, and a mutable MessageHeader. These are the foundations for the other message classes. Everything is represented in a single byte[]. If you want to create a message header that uses a plain CR as a line separator, go ahead and construct a byte[] that has the lines separated by CR's, and call setHeader(). Of course, the convenience methods are configured to expect CRLF, and so if you call any of those methods, you should expect to receive a MessageFormatException, and be prepared to parse the header manually.

===Message Content===

public interface StreamingMessage extends MutableMessageHeader {
InputStream getContent();
InputStream getDecodedContent() throws MessageFormatException;
void setContent(InputStream content);
void setDecodedContent(InputStream content) throws MessageFormatException;
}

public interface BufferedMessage extends MessageHeader {
byte[] getContent();
byte[] getDecodedContent() throws MessageFormatException;
}

public interface MutableBufferedMessage extends BufferedMessage, MutableMessageHeader {
void setContent(byte[] content);
void setDecodedContent(byte[] content) throws MessageFormatException;
}

The above interfaces represent the content of an HTTP message, either in a streaming or buffered state. Streaming messages are useful if you only really want to look at the message header, and not do anything with the message body, or if you can process the message body in a streaming fashion.

For example, you may want to compress a message transferred without gzip encoding. Update the message header to reflect the new encoding, wrap the content stream with a suitable GzipInputStream, and pass the message on to the next layer.

Of course, if you want to do something complex with the message body, you probably want to work with the buffered content. In that case, the BufferedMessage and MutableBufferedMessage interfaces are appropriate.

Note: There is a distinction between BufferedMessage and MutableBufferedMessage mainly as documentation indicating whether they should be modified or not in a particular method. See BufferedMessageInterceptor, for example.

===Requests and Responses===

This is what a Request header looks like. Again, there are convenience methods to obtain specific portions of the request, but underneath it all is that byte[] containing the entire header.

public interface RequestHeader extends MessageHeader {
InetSocketAddress getTarget();
boolean isSsl();
String getMethod() throws MessageFormatException;
String getResource() throws MessageFormatException;
String getVersion() throws MessageFormatException;
}

public interface MutableRequestHeader extends RequestHeader, MutableMessageHeader {
void setTarget(InetSocketAddress target);
void setSsl(boolean ssl);
void setMethod(String method) throws MessageFormatException;
void setResource(String resource) throws MessageFormatException;
void setVersion(String version) throws MessageFormatException;
}

Note that the target server and whether the message should be encrypted or not is external to the message header itself. In most cases, where no upstream proxy is involved, sending the request is as simple as opening a socket to the target InetSocketAddress, and calling write(message.getHeader()); Again, the minimum of parsing is performed, to allow for sending non-RFC compliant messages to a server.

There are similar interfaces for Responses, although they do not have an associated target.

==Intercepting HTTP Messages==

OWASP Proxy provides a BufferingHttpRequestHandler class which interacts with implementations of the BufferedMessageInterceptor interface to facilitate manipulation of the request and response.

This is what the BufferedMessageInterceptor interface looks like:

public interface BufferedMessageInterceptor {

enum Action { BUFFER, STREAM, IGNORE};

Action directRequest(MutableRequestHeader request);
void processRequest(MutableBufferedRequest request);
void requestContentSizeExceeded(BufferedRequest request, int size);
void requestStreamed(BufferedRequest request);

Action directResponse(RequestHeader request, MutableResponseHeader response)
void processResponse(RequestHeader request, MutableBufferedResponse response)
void responseContentSizeExceeded(RequestHeader request, ResponseHeader response, int size);
void responseStreamed(final RequestHeader request, BufferedResponse response);

}

Note: BufferedMessageInterceptor is actually an abstract class, to save implementation of methods that you have no interest in.

The first thing to do is decide which requests and responses your implementation is interested in. The "directRequest()" method is called first, with the RequestHeader as a parameter. Examine the request header to determine if the request is "interesting" or not. If you want the request content to be buffered, return Action.BUFFER. If you want the request content to be streamed to the server, return Action.STREAM. If you are not interested in any part of the request, you can return Action.IGNORE, and no further methods will be called for that particular Request/Response.

Note that the RequestHeader is actually Mutable, so if you are only interested in the header, you can make any changes you like in this method, and then return either Action.STREAM or Action.IGNORE, and forget about it.

The methods that will be invoked next depend on the Action that was returned.

If the Action was BUFFER, the processRequest(MutableBufferedRequest) method will be called, with the buffered request as a parameter. You can then modify it to suit, and when you return from this method, the buffered request will be sent to the server.

If the action was STREAM, the requestStreamed(BufferedRequest) method will be called. Note that this request is no longer mutable, as it is only invoked AFTER the entire request body has been streamed to the server.

Note: BufferingHttpRequestHandler takes a "max content size" parameter, to avoid buffering excessively large messages, and potentially running out of memory. If the limit is reached, the requestContentSizeExceeded(BufferedRequest, size) method is invoked, with the BufferedRequest containing the bytes buffered up to the size limit, and the size parameter containing the ultimate size of the message.

The same process is followed for the Response cycle. Determine if you are interested in the response, return a suitable Action, and handle the response in the appropriate methods thereafter.

==Putting an intercepting proxy together==

HttpRequestHandler requestHandler = new DefaultHttpRequestHandler();
BufferedMessageInterceptor interceptor = new BufferedMessageInterceptor() {
public Action directResponse(RequestHeader request, MutableResponseHeader response) {
return Action.BUFFER;
}

public void processResponse(RequestHeader request, MutableBufferedResponse response) {
try {
System.out.println(request.getResource() + " : “ + response.getDecodedContent().length);
} catch (MessageFormatException mfe) {
mfe.printStackTrace();
}
}
};
int maxContentSize = 10240;
requestHandler = new BufferingHttpRequestHandler(requestHandler, interceptor, maxContentSize);
ConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
InetSocketAddress listen = new InetSocketAddress("localhost", 8008);
Server proxy = new Server(listen, httpProxy);
proxy.start();

This constructs a very simple interceptor that just prints out the resource path, and the size of the decoded content.

==Can we add SSL intercept?==

Absolutely!

char[] password = "password".toCharArray();
HttpConnectionHandler httpProxy = new HttpProxyConnectionHandler(requestHandler);
SSLContextSelector contextSelector = new DefaultServerContextSelector(“server.p12", password, password);
SSLConnectionHandler ssl = new SSLConnectionHandler(contextSelector, true, httpProxy); // true -> autodetect SSL
httpProxy.setConnectHandler(ssl);
Server proxy = new Server(listen, httpProxy);

This constructs an SSLConnectionHandler that automatically detects an incoming SSL connection based on the first few bytes read from the connection, negotiates an SSL Server connection with the client using the supplied certificate in the "server.p12" PKCS#12 file, then passes the decrypted connection on to the HttpProxyConnectionHandler. It also installs that same SSLConnectionHandler as the ConnectHandler of the HttpProxyConnectionHandler. i.e. when the HTTP Proxy receives a CONNECT request, after it is permitted, the raw byte stream is then passed back to the SSLConnectionHandler.

===How can we avoid browser warnings about untrusted connections?===

One problem with intercepting proxies that manifests when intercepting SSL connections is that traditionally the browser will present a warning to the user that the certificate used is invalid, and thus the connection is untrusted. In many cases, this is easily worked around by accepting the untrusted connection, and continuing, but for AJAX-y connections, there is no opportunity to accept that warning, and the site just ends up being non-functional.

OWASP Proxy includes a Sun JRE-specific class that uses Sun-internal classes to generate and sign a CA keypair and certificate, and then uses that to sign server-specific certificates. This means that if the CA certificate is imported into the browser, any further certificates signed by that CA certificate will automatically be trusted.

SSLContextSelector contextSelector = new AutoGeneratingContextSelector("keystore", "JKS", password);

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project|Proxy Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Alpha Quality Tool]]

Category:OWASP Proxy

2010-03-18T19:38:12Z

RoganDawes: Provide up to date examples

Category:OWASP Proxy

2010-03-18T18:52:08Z

RoganDawes: /* Implementation details */

GPC Project Details/OWASP WebScarab Project

2009-11-20T13:12:10Z

RoganDawes: Filled in a couple of details

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP Project Identification Tab</noinclude>
| project_name = OWASP WebScarab Project
| project_description = WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms.
| project_license = GPL
| leader_name = Rogan Dawes
| leader_email = rogan@dawes.za.net
| leader_username = RoganDawes
| past_leaders_special_contributions =
| maintainer_name =
| maintainer_email =
| maintainer_username =
| contributor_name1 =
| contributor_email1 =
| contributor_username1 =
| contributor_name2 =
| contributor_email2 =
| contributor_username2 =
| contributor_name3 =
| contributor_email3 =
| contributor_username3 =
| contributor_name4 =
| contributor_email4 =
| contributor_username4 =
| contributor_name5 =
| contributor_email5 =
| contributor_username5 =
| contributor_name6 =
| contributor_email6 =
| contributor_username6 =
| contributor_name7 =
| contributor_email7 =
| contributor_username7 =
| contributor_name8 =
| contributor_email8 =
| contributor_username8 =
| contributor_name9 =
| contributor_email9 =
| contributor_username9 =
| contributor_name10 =
| contributor_email10 =
| contributor_username10 =
| pamphlet_link =
| presentation_link =
| mailing_list_name = owasp-webscarab@lists.owasp.org
| links_url1 =
| links_name1 =
| links_url2 =
| links_name2 =
| links_url3 =
| links_name3 =
| links_url4 =
| links_name4 =
| links_url5 =
| links_name5 =
| links_url6 =
| links_name6 =
| links_url7 =
| links_name7 =
| links_url8 =
| links_name8 =
| links_url9 =
| links_name9 =
| links_url10 =
| links_name10 =
| project_road_map = :Category:OWASP WebScarab Project - Roadmap
| project_health_status = Inactive
| current_release_name = First Release
| current_release_date =
| current_release_download_link =
| current_release_rating =
| current_release_leader_name =
| current_release_leader_email =
| current_release_leader_username =
| current_release_details = :Category:OWASP WebScarab Project - First Release
| last_reviewed_release_name =
| last_reviewed_release_date =
| last_reviewed_release_download_link =
| last_reviewed_release_rating =
| last_reviewed_release_leader_name =
| last_reviewed_release_leader_email =
| last_reviewed_release_leader_username =
| last_reviewed_release_details =
| old_release_name1 =
| old_release_date1 =
| old_release_download_link1 =
| old_release_name2 =
| old_release_date2 =
| old_release_download_link2 =
| old_release_name3 =
| old_release_date3 =
| old_release_download_link3 =
| old_release_name4 =
| old_release_date4 =
| old_release_download_link4 =
| old_release_name5 =
| old_release_date5 =
| old_release_download_link5 =
| last_GPC_update = 2/10/2009
| GPC_Notes = Empty template
| project_home_page = Category:OWASP_WebScarab_Project
| project_details_wiki_page = GPC_Project_Details/OWASP_WebScarab_Project
}}

Global Projects and Tools Committee - Application 2

2009-05-05T13:32:34Z

RoganDawes: Add support

[[How to Join a Committee|Click here to return to 'How to Join a Committee' page]]

----
{| style="width:100%" border="0" align="center"
! colspan="2" align="center" style="background:#4058A0; color:white"|'''COMMITTEE APPLICATION FORM'''
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Applicant's Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|Brad Causey
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Current and past OWASP Roles'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|OWASP OpenPGP Extensions for HTTP Reviewer
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Committee Applying for'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|Global Projects and Tools Committee
|}
----

----
Please be aware that for an application to be considered by the board, '''you MUST have 5 recommendations'''.
An incomplete application will not be considered for vote.
----

----
{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''COMMITTEE RECOMMENDATIONS'''
|-
! align="center" style="background:white; color:white"|
! align="center" style="background:#7B8ABD; color:white"|'''Who Recommends/Name'''
! align="center" style="background:#7B8ABD; color:white"|'''Role in OWASP'''
! align="center" style="background:#7B8ABD; color:white"|'''Recommendation Content'''
|-
| style="width:3%; background:#cccccc" align="center"|'''1'''
| style="width:20%; background:#cccccc" align="center"|Arturo Busleiman (a.k.a Buanzo)
| style="width:20%; background:#cccccc" align="center"|Project Leader
| style="width:57%; background:#cccccc" align="center"|Brad is an exceptional individual, a through professional. OWASP would only get better with him in the Projects and Tools Committee. I met him during OWASP EU Summit 2008 in Portugal. Matt Tesauro, himself and I worked together to give a presentation on security at the Algarve University with < 12 hours to spare. Brad is great at getting feedback, combining ideas. A must.
|-
| style="width:3%; background:#cccccc" align="center"|'''2'''
| style="width:20%; background:#cccccc" align="center"|Rogan Dawes
| style="width:20%; background:#cccccc" align="center"|Project Leader
| style="width:57%; background:#cccccc" align="center"|I think Brad would make an excellent addition to the Committee. He is an exceptional individual, technically excellent as well as committed to ensuring the success of OWASP.
|-
| style="width:3%; background:#cccccc" align="center"|'''3'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|-
| style="width:3%; background:#cccccc" align="center"|'''4'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|-
| style="width:3%; background:#cccccc" align="center"|'''5'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:57%; background:#cccccc" align="center"|
|}
----

Project Information:template SKAVENGER - Final Review - First Reviewer - D

2009-02-27T12:14:01Z

RoganDawes: Completion

[[Project Information:template SKAVENGER|Click here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Project Deliveries & Objectives '''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#Skavenger|Skavenger Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#Skavenger|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#Skavenger|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- 100%
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- Since the targeted proxies are mostly (all?) Java based, would it not make sense to port the analysis portion of Skavenger from Perl to Java, facilitating integration?
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Assessment Criteria'''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template SKAVENGER - Final Review - First Reviewer - D

2009-02-27T11:34:59Z

RoganDawes: completion

[[Project Information:template SKAVENGER|Click here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Project Deliveries & Objectives '''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#Skavenger|Skavenger Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#Skavenger|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- From my assessment of Skavenger, all project objectives have been met.
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications - Need Futher Clarifications#Skavenger|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- 100%
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- It seems that the majority (all?) of proxies targeted by Skavenger are Java based. Consequently, it would make sense to reimplement the Skavenger core in Java to facilitate integration with the targeted proxies.
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
'''Assessment Criteria'''
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|- None
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Category:OWASP WebScarab Project

2009-02-24T16:28:51Z

RoganDawes: Add a link to a continuous build product

{{OWASP Book|1416452}}

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

You may also be interested in testing the [[OWASP WebScarab NG Project | Next Generation of WebScarab]].

==Screenshots==

Here's the main window of WebScarab. Check the [[WebScarab Getting Started]] guide for more screenshots of WebScarab in action.

[[Image:WebScarab after browsing.png]]

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP subscription page], and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

A ZIP containing an up to date build of the master branch of the [http://dawes.za.net/gitweb.cgi?p=rogan/webscarab/webscarab.git;a=shortlog;h=refs/heads/master webscarab git tree] can be found [http://dawes.za.net/rogan/webscarab/webscarab-current.zip here]. This ZIP is rebuilt whenever new commits are pushed to the repository, and will always be the most up to date build of WebScarab available.

Alternatively, you can download older builds of WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge]. Then install them likewise:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: double-click the installer jar file [http://www.acsac.org/2007/downloads/t5-webscarab-instructions.pdf (complete installation instructions)])

A Mac OS X package of the latest version can usually be found on [http://research.corsaire.com/tools/ Corsaire's download page].

You can also try the [http://dawes.za.net/rogan/webscarab/WebScarab.jnlp Java Web Start version], which was signed by Rogan Dawes.

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyses a number of cookies to visually determine the degree of randomness and unpredictability. Note that this analysis is rather trivial, and does not do any serious checks, such as FIPS, etc.

* Scripted - operators can use BeanShell (or any other BSF supported language found on the classpath) to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server. '''NOTE''': This plugin is deprecated, and may be removed in the future. [http://www.soapui.org SOAPUI] is streets beyond anything that Webscarab can do, or will ever do, and is also a free tool.

* Extensions - automates checks for files that were mistakenly left in web server's root directory (e.g. .bak, ~, etc). Checks are performed for both, files and directories (e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Extensions for files and directories can be edited by user.

* XSS/CRLF - passive analysis plugin that searches for user-controlled data in HTTP response headers and body to identify potential CRLF injection (HTTP response splitting) and reflected cross-site scripting (XSS) vulnerabilities.

==Training Material==

Aung Khant (YGN Ethical Hacker Group, Myanmar) has created a series of WebScarab movies which can be found [http://yehg.net/lab/pr0js/training/webscarab.php here].

There are slides of the presentation "Uncovering Webscarab's Hidden Treasures", given at the OWASP EU Summit 2008, available [https://www.owasp.org/images/8/88/OWASP_EU_Summit_2008_WebScarab_treasures.ppt here].

==Future development==

Features will probably include:

* Combining the Search and Compare plugins, so that you can compare only specific responses

* Improving the fuzzer, adding ability to follow redirects, or to specify the number of threads to use. Also, adding the ability to define what is (or isn't) interesting in the fuzz results, and save only interesting conversations to the summary.

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP Release Quality Tool]]

Category:OWASP Skavenger Project - Assessment Frame

2009-02-13T19:42:52Z

RoganDawes: Final review

[[:Category:OWASP Skavenger Project|Click here to return to project's main page]].
{| style="width:100%" border="0" align="center"
! colspan="2" align="center" style="background:#4058A0; color:white"|'''PROJECT IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|'''OWASP Skavenger Project'''
|}
{| style="width:100%" border="0" align="center"
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS - OWASP Summer of Code 2008
|-
| style="width:15%; background:#6C82B5" align="center"|'''Reviewer'''
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation''' [[User:Mrohr|'''Matthias Rohr''']]
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer''' [[:User:RoganDawes|'''Rogan Dawes''']]
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer''' [[:User:Achim|'''Achim Hoffmann''']]
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member''' Non applicable
|-
| style="width:15%; background:#7B8ABD" align="center"|'''50% Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- [[Project Information:template SKAVENGER - 50 Review - Self Evaluation - A|Self - Evaluation (A)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- [[Project Information:template SKAVENGER - 50 Review - First Reviewer - C|First Reviewer (C)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- [[Project Information:template SKAVENGER 50 Review Second Review E|Second Reviewer (E)]]
| style="width:22%; background:#C2C2C2" align="center"|X
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Final Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- Which status has been reached? '''Beta Quality''' --------- [[Project Information:template SKAVENGER - Final Review - Self Evaluation - B|Self - Evaluation (B)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- Which status has been reached? '''Beta Quality''' --------- [[Project Information:template SKAVENGER - Final Review - First Reviewer - D|First Reviewer (D)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Season of Code''' - (To update) --------- [[Project Information:template SKAVENGER - Final Review - Second Reviewer - F|Second Reviewer (F)]]
| style="width:22%; background:#C2C2C2" align="center"|X
|}

Project Information:OWASP Proxy Project

2009-01-30T17:47:41Z

RoganDawes: Add a link to a source snapshot

----
{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''PROJECT INFORMATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|'''OWASP Proxy Project'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|
The OWASP Proxy aims to provide a high quality intercepting proxy library which can be used by developers who require this functionality in their own programs, rather than having to develop it all from scratch.

The library is developed in Java, making it most attractive to Java developers obviously, but also accessible to Python (Jython) and Ruby (JRuby) developers as well.
|-
| style="width:15%; background:#7B8ABD" align="center"|
'''Key Project Information'''
| style="width:14%; background:#cccccc" align="center"|
Project Leader [[:User:RoganDawes|'''Rogan Dawes''']]
| style="width:15%; background:#cccccc" align="center"|
Project Contibutors [[:User:name|'''Add name''']]
| style="width:10%; background:#cccccc" align="center"|
Mailing List [https://lists.owasp.org/mailman/listinfo/owasp-proxy-project '''Subscribe here'''] [mailto:owasp-proxy-project@lists.owasp.org '''Use here''']
| style="width:17%; background:#cccccc" align="center"|
License [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''']
| style="width:14%; background:#cccccc" align="center"|
Project Type [[:Category:OWASP_Project#Alpha_Status_Projects|'''Tool''']]
| style="width:15%; background:#cccccc" align="center"|
Sponsors if any, add link
|}
{| style="width:100%" border="0" align="center"
! align="center" style="background:#7B8ABD; color:white"|'''Release Status'''
! align="center" style="background:#7B8ABD; color:white"|'''Main Links'''
! align="center" style="background:#7B8ABD; color:white"|'''Related Projects'''
|-
| style="width:29%; background:#cccccc" align="center"|
'''[[:Category:OWASP Project Assessment#Alpha Quality Tool Criteria|Alpha Quality]]''' (under review) [[:OWASP Proxy Project - Assessment Frame|Please see here for complete information.]]
| style="width:42%; background:#cccccc" align="center"|
At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here]. An up to date snapshot can be obtained [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=snapshot;h=HEAD;sf=tgz here].
| style="width:29%; background:#cccccc" align="center"|
* [[:Category:OWASP WebScarab Project|WebScarab]]
* [[:Category:OWASP CSRFTester Project|CSRFTester]]
|}
----

Project Information:OWASP Proxy Project

2009-01-30T17:25:05Z

RoganDawes: add links to related projects

----
{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''PROJECT INFORMATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|'''OWASP Proxy Project'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Project Description'''
| colspan="7" style="width:85%; background:#cccccc" align="left"|
The OWASP Proxy aims to provide a high quality intercepting proxy library which can be used by developers who require this functionality in their own programs, rather than having to develop it all from scratch.

The library is developed in Java, making it most attractive to Java developers obviously, but also accessible to Python (Jython) and Ruby (JRuby) developers as well.
|-
| style="width:15%; background:#7B8ABD" align="center"|
'''Key Project Information'''
| style="width:14%; background:#cccccc" align="center"|
Project Leader [[:User:RoganDawes|'''Rogan Dawes''']]
| style="width:15%; background:#cccccc" align="center"|
Project Contibutors [[:User:name|'''Add name''']]
| style="width:10%; background:#cccccc" align="center"|
Mailing List [https://lists.owasp.org/mailman/listinfo/owasp-proxy-project '''Subscribe here'''] [mailto:owasp-proxy-project@lists.owasp.org '''Use here''']
| style="width:17%; background:#cccccc" align="center"|
License [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''']
| style="width:14%; background:#cccccc" align="center"|
Project Type [[:Category:OWASP_Project#Alpha_Status_Projects|'''Tool''']]
| style="width:15%; background:#cccccc" align="center"|
Sponsors if any, add link
|}
{| style="width:100%" border="0" align="center"
! align="center" style="background:#7B8ABD; color:white"|'''Release Status'''
! align="center" style="background:#7B8ABD; color:white"|'''Main Links'''
! align="center" style="background:#7B8ABD; color:white"|'''Related Projects'''
|-
| style="width:29%; background:#cccccc" align="center"|
'''[[:Category:OWASP Project Assessment#Alpha Quality Tool Criteria|Alpha Quality]]''' (under review) [[:OWASP Proxy Project - Assessment Frame|Please see here for complete information.]]
| style="width:42%; background:#cccccc" align="center"|
At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].
| style="width:29%; background:#cccccc" align="center"|
* [[:Category:OWASP WebScarab Project|WebScarab]]
* [[:Category:OWASP CSRFTester Project|CSRFTester]]
|}
----

Generating Custom SSL Certificates for WebScarab

2009-01-09T10:15:00Z

RoganDawes: Fix up some phrasing, removed the embedded copy of the script, make sure that the link always points to the latest version in the repo

When using WebScarab to proxy SSL conversations, you may want to avoid the somewhat annoying warnings for an unrecognized certificate. You can generate a custom SSL certificate to remove these warning messages and it's rather straight forward if you have a sufficiently recent version of WebScarab (initial support was added on 2008/08/05). Read on to see how.

== Background ==

Below is an illustration of what happens when WebScarab is used as a intercepting proxy for SSL connections.

<pre> -------- ----------- ---------
| server |<--[1]-->| WebScarab |<--[2]-->| browser |
-------- ----------- ---------</pre>

For [1], you are using the "real" SSL certificate from the website you are browsing to. That SSL certificate is signed by a recognized certificate authority (CA). The thing that makes those CA's special is that browsers know about them and trust them. For example in Firefox:
# Open Edit -> Preferences -> Advanced -> Encryption
# View Certificates button
# Authorities tab
to see a list of built-in trusted CA's.
The only thing that needs to trust this certificate is WebScarab, which trusts all certificates, whether valid or not.

For [2], you are using the the self-signed server.p12 certificate which comes with WebScarab. The difference between [1] and [2] is that the
CA which signed that certs is NOT built into browsers so they do not trust them by default. Additionally, the domain name of this certificate will not match the domain your browser is accessing. The default is the webscarab CA and a host name of webscarab.

== Generating a Certificate ==

Since your browser doesn't trust the CA which signed server.p12 in [2] above, you've got two choices:
# Instruct the browser to trust the certificate. This will work for the CA part but not for the host name. You will still be prompted by the browser so this doesn't really help much, and is not advised anyway, due to the fact that lots of people have this CA cert, and could use it to create SSL certificate for arbitrary sites. I know that you can have Firefox trust the CA used in [2] permanently - though it's a bunch of clicks in Firefox 3 - about 6 or 7 clicks and you still have the host name mis-match issue.

# Use a .p12 file & CA certificate. You'll have to have WebScarab use the new .p12 file and install the CA certificate into your browser.

There is a script to do this in the WebScarab Git repository. You can get it [http://dawes.za.net/gitweb.cgi?p=rogan/webscarab/webscarab.git;a=blob;f=doc/cert.sh;hb=master here].

The script will create a server-specific key and certificate for the site provided as a parameter on the command line. If this is the first time the script is being run, it will also create a CA cert which you can then import into your browser(s).

If you called that script like:
<pre>$ ./cert.sh www.example.com</pre>
It will generate a bunch of output and create a www.example.com.p12 file for WebScarab and a ca_cert.pem file (this is the CA used to sign www.example.com.p12). The script will run fine on Linux (I just tried it) and possibly OS X but will only work on Windows under Cygwin.

Take the www.example.com.p12 (assuming you ran the script like above) and let WebScarab know about it. To do this you will need to place it in ${WEBSCARAB_HOME}/certs/. WebScarab checks in that directory whenever a request is made for an SSL site, for a file <sitename>.p12, and will use it in preference to the default server cert if one is found.

Take the ca_cert.pem file and configure your browser to trust that CA. For Firefox:
# Open Edit -> Preferences -> Advanced -> Encryption
# View Certificates button
# Authorities
# Click the Import button and navigate to the ca_cert.pem file

Make sure you at least check the box "Trust this CA to identify web sites." option when you are importing - it will bring up a window with that information.

For IE, I don't know off the top of my head. Try this [http://www.library.jcu.edu.au/LibraryGuides/certificate.shtml link] except for instead of downloading it you can right-click on the ca_cert.pem file and select "Install Certificate"

FYI: Firefox and IE will both need to be configured if both are used as they keep their lists of trusted CAs in different places.

'''Added Bonus'''
If you keep the working directory for cert.sh (recommended!), you can create new custom SSL certificates and not need to import a new CA cert. If you know all the domains you'll be testing, you can run cert.sh multiple times and just restart WebScarab once to get them all recognized.

For the curious, this is the directory structure the cert.sh script creates:
<pre>./
|-- cert.sh
|-- sslcerts
| |-- ca_cert.pem
| |-- certindex.txt
| |-- certindex.txt.attr
| |-- certindex.txt.old
| |-- certs
| | `-- 100001.pem
| |-- openssl.cnf
| |-- private
| | |-- ca_key.pem
| | `-- www.example.com-key.pem
| |-- serial
| |-- serial.old
| |-- www.example.com-cert.pem
| `-- www.example.com-req.pem
`-- www.example.com.p12

3 directories, 14 files </pre>

== Notes ==

# I was not precise in terms and used SSL and HTTPS loosely in the above. This process would also applies to TLS - I just didn't want to type SSL/TLS over and over.
# Matt Tesauro was the author of this document. If you have corrections, feel free to make them yourself (its a Wiki after all) or contact Matt at mtesauro (at) gmail.com

[[Category:OWASP WebScarab Project]]

Category:OWASP Proxy

2009-01-05T20:45:59Z

RoganDawes: Update code explaining how to extend the library

'''Welcome to the OWASP Proxy'''

The OWASP Proxy aims to provide a high quality intercepting proxy library which can be used by developers who require this functionality in their own programs, rather than having to develop it all from scratch.

The library is developed in Java, making it most attractive to Java developers obviously, but also accessible to Python (Jython) and Ruby (JRuby) developers as well.

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is always stored as a large byte[].

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Listener and a HTTP client implementation.

==Extending the OWASP Proxy==

The basic classes are Listener and SocksListener, which can be customised to add your own functionality. If you just create an instance of Listener (or SocksListener), it will accept connections on the specified port, and relay them to the requested destination.

Listener l = new Listener(8008); // listens to localhost by default
Listener sl = new SocksListener(1080);

or

Listener l = new Listener(InetAddress.getByAddress(new byte[] { 127, 0,
0, 1 }), 8008);
Listener sl = new SocksListener(InetAddress.getByAddress(new byte[] { 127, 0,
0, 1 }), 1080);

The first thing a developer might want to do is make some changes to the request or response. This is done by means of a ProxyMonitor. This is an abstract class that can be extended to provide the specific functionality required. I'll show it here as an interface, just to reduce verbosity.

Response requestReceived(Request request)
throws MessageFormatException;

Response errorReadingRequest(Request request, Exception e)
throws MessageFormatException;

boolean responseHeaderReceived(Conversation conversation)
throws MessageFormatException;

void responseContentReceived(Conversation conversation, boolean streamed)
throws MessageFormatException;

Response errorFetchingResponseHeader(Request request, Exception e)
throws MessageFormatException;

Response errorFetchingResponseContent(Conversation conversation, Exception e)
throws MessageFormatException;

void wroteResponseToBrowser(Conversation conversation)
throws MessageFormatException;

void errorWritingResponseToBrowser(Conversation conversation,
Exception e) throws MessageFormatException;

These methods are called at various stages of a request's lifecycle, if appropriate. Obviously error methods won't be called if there are no errors! Each method that returns a Response object can be customized to return a custom Response to the browser. e.g. overriding requestReceived(Request) can allow a developer to provide a browser-based interface to their program, by returning Response objects for specific requests, e.g. to a host called "proxy":

public Response requestReceived(Request request)
throws MessageFormatException {
if (request.getHost().equals("proxy")) {
return handleRequest(request);
}
return super.requestReceived(request);
}

The library provides a LoggingProxyMonitor class, which simply logs the Requests and Responses that pass through. It also prints out any exceptions that may occur (not shown).

class LoggingProxyMonitor extends ProxyMonitor {

@Override
public void wroteResponseToBrowser(Conversation conversation)
throws MessageFormatException {
try {
int resp = conversation.getResponse().getMessage().length;
long time = conversation.getResponseBodyTime()
- conversation.getRequestTime();

Request request = conversation.getRequest();
StringBuilder buff = new StringBuilder();
buff.append(request.getMethod()).append(" ");
buff.append(request.isSsl() ? "ssl " : "");
buff.append(request.getHost()).append(":")
.append(request.getPort());
buff.append(request.getResource()).append(" ");
buff.append(conversation.getResponse().getStatus()).append(" - ")
.append(resp);
buff.append(" bytes in ").append(time).append("(").append(
resp / (time * 1000));
buff.append(" bps)");
System.out.println(buff.toString());
} catch (MessageFormatException mfe) {
}
}
}

One thing that a developer might want to do is teach the proxy how to use an upstream proxy to reach the target. OWASP Proxy uses the standard Java ProxySelector mechanism for this:

final Proxy upstream = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(host, port);

final ProxySelector ps = new ProxySelector() {

@Override
public void connectFailed(URI uri, SocketAddress sa, IOException ioe) {
System.err.println("Proxy connection failed! "
+ ioe.getLocalizedMessage());
}

@Override
public List<Proxy> select(URI uri) {
return Arrays.asList(upstream);
}
};

Having created the ProxySelector, we need to make use of it. OWASP Proxy has its own Http Client implementation, that specifically makes NO unnecessary changes to the requests or responses. Some libraries try to make sure that the requests it sends are well-formed, for instance, but for a security tool, sometimes it is interesting to send malformed requests.

So, we can tell the Listener how to configure its HttpClient implementations, by providing a customised HttpClientFactory:

HttpClientFactory hcf = new DefaultHttpClientFactory() {

@Override
public HttpClient createHttpClient() {
HttpClient client = super.createHttpClient();
client.setProxySelector(ps);
return client;
}
};
listener.setHttpClientFactory(hcf);

By default, OWASP Proxy does not intercept SSL connections (HTTP CONNECT verb), and if it encounters an SSL encrypted channel, it simply refuses to continue. Developers can enable SSL interception by providing a CertificateProvider implementation.

This is what the interface looks like:

public interface CertificateProvider {

SSLSocketFactory getSocketFactory(String host, int port) throws IOException;

}

A simple implementation is provided in DefaultCertificateProvider that makes use of a single certificate for all connection attempts. A certificate location and passwords can be provided; alternatively, OWASP Proxy's default certificate can be used.

listener.setCertificateProvider(new DefaultCertificateProvider());

Developers may wish to make use of something like the CyberVillains CA library to automatically generate certificates on the fly for each site visited.

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]

Category:OWASP Proxy

2008-12-17T20:09:22Z

RoganDawes: Introduce the OWASP Proxy

'''Welcome to the OWASP Proxy'''

The OWASP Proxy aims to provide a high quality intercepting proxy library which can be used by developers who require this functionality in their own programs, rather than having to develop it all from scratch.

The library is developed in Java, making it most attractive to Java developers obviously, but also accessible to Python (Jython) and Ruby (JRuby) developers as well.

==Overview==

One of the priorities of this project is to allow developers to do whatever they choose, without enforcing RFC compliance. This is important for a security testing library, as often the most interesting behavior manifests outside the RFCs! Keep in mind that a lot of the safety nets that exist in libraries that enforce RFC compliance do not exist in this library, and that as the developer, you need to be prepared to deal with the consequences!

Another priority is to accurately deliver whatever is specified by the client, and similarly, to accurately reflect whatever is returned by the server, rather than coloured by the parsing and normalisation performed by the library.

==Download==

At the moment there is no packaged version of this library. Development is done in a git repository, located [http://dawes.za.net/gitweb.cgi?p=rogan/owasp-proxy/owasp-proxy.git;a=summary here].

Interested parties can download a snapshot of the code at any point using the snapshot link next to each revision, or clone the repository:

$ git clone http://dawes.za.net/rogan/owasp-proxy/owasp-proxy.git/

==Implementation details==

In order to achieve byte for byte accuracy with what was sent by the client, and received from the server, OWASP Proxy does the bare minimum of message parsing. The basic storage of an HTTP message is as an array of byte (a byte for byte copy of what was read from the network), rather than parsed out into convenient pieces. The library does provide convenience methods for accessing interesting parts of the message, such as headers, content, etc, but the message itself is always stored as a large byte[].

The Request and Response objects that you may deal with also do not decode the message bodies for you. If the message was sent using chunked encoding, the message body will show the individual chunks that were sent. Of course, again, there are also classes which allow you to obtain the actual entity body, with appropriate decoding.

==Future development==

As mentioned above, one objective is correctness. By this I mean correctly handling whatever the major browsers send to it, and successfully retrieving whichever resource was requested. Failure to do so will be addressed as soon as possible.

Other than that, there is no intention to add major new features to the library above those required to fulfill its purpose as a Lstener and a HTTP client implementation.

One feature which is under serious consideration is the ability to proxy upstream requests via a SOCKS proxy, for example, as implemented by OpenSSH.

==Extensibility==

The library attempts to provide the necessary extension points to allow developers access to the major lifecycle events of a request and a response. Here are the major methods that can be overridden:

/**
* Override this method to control SSL support.
* Return null to disable SSL CONNECT support
*
* @param host
* the host that the client wishes to CONNECT to
* @param port
* the port that the client wishes to CONNECT to
* @return an SSLSocketFactory generated from the relevant server key
* material, or null to disable CONNECT support
*/
protected SSLSocketFactory getSocketFactory(String host, int port) {
return null;
}

/**
* Override this method to configure your HttpClient.
* For example, configure it to use an upstream proxy
*
* @return a preconfigured HttpClient
*/
protected HttpClient createHttpClient() {
return new HttpClient();
}

A developer wishing to implement an in-browser interface to their application can override this method. If the request refers to your UI, simply return an appropriate Response here, and that Response will be returned to the client. Returning null will allow the (possibly modified) Request to be sent on to the server.

/**
* Called when a request is received by the proxy. Changes can be made to
* the Request object to alter what will be sent to the server.
*
* @param request
* the Request received from the client
* @return a custom Response to be sent directly back to the client without
* making any request to a server, or null to forward the Request
* @throws MessageFormatException
* if the request cannot be parsed
*/
protected Response requestReceived(Request request)
throws MessageFormatException {
return null;
}

/**
* Called when an error is encountered while reading the request from the
* client.
*
* @param request
* @param e
* @return a customized Response to be sent to the browser, or null to send
* the default error message
* @throws MessageFormatException
* if the request couldn't be parsed
*/
protected Response errorReadingRequest(Request request, Exception e)
throws MessageFormatException {
return null;
}

/**
* Called when the Response headers have been read from the server. The
* response content (if any) will not yet have been read. Analysis can be
* performed based on the headers to determine whether to intercept the
* complete response at a later stage. If you wish to intercept the complete
* response message at a later stage, return false from this method to
* disable streaming of the response content, otherwise the response would
* already have been written to the browser when responseContentReceived is
* called.
*
* Note: If you modify the response headers in this method, be very careful
* not to affect the retrieval of the response content. For example,
* deleting a "Transfer-Encoding: chunked" header would be a bad idea!
*
* @param conversation
* @return true to stream the response to the client as it is being read
* from the server, or false to delay writing the response to the
* client until after responseContentReceived is called
* @throws MessageFormatException
* if either the request or response couldn't be parsed
*/
protected boolean responseHeaderReceived(Conversation conversation)
throws MessageFormatException {
return true;
}

/**
* Called after the Response content has been received from the server. If
* streamed is false, the response can be modified here, and the modified
* version will be written to the client.
*
* @param conversation
* @param streamed
* true if the response has already been written to the client
* @throws MessageFormatException
* if either the request or response couldn't be parsed
*/
protected void responseContentReceived(Conversation conversation,
boolean streamed) throws MessageFormatException {
}

/**
* Called in the event of an error occurring while reading the response
* header from the client
*
* @param request
* @param e
* @return a custom Response to be sent to the client, or null to use the
* default
* @throws MessageFormatException
* if either the request or response couldn't be parsed
*/
protected Response errorFetchingResponseHeader(Request request, Exception e)
throws MessageFormatException {
return null;
}

/**
* Called in the event of an error occurring while reading the response
* content from the client
*
* @param conversation
* @param e
* @return a custom Response to be sent to the client, or null to use the
* default
* @throws MessageFormatException
* if either the request or response couldn't be parsed
*/
protected Response errorFetchingResponseContent(Conversation conversation,
Exception e) throws MessageFormatException {
return null;
}

protected void wroteResponseToBrowser(Conversation conversation)
throws MessageFormatException {
}

protected void errorWritingResponseToBrowser(Conversation conversation,
Exception e) throws MessageFormatException {
}

==Project Contributors==

The OWASP Proxy project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]

Category:OWASP WebScarab Project

2008-11-07T11:34:36Z

RoganDawes: Spelling fix

{{OWASP Book|1416452}}

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

You may also be interested in testing the [[OWASP WebScarab NG Project | Next Generation of WebScarab]].

==Screenshots==

Here's the main window of WebScarab. Check the [[WebScarab Getting Started]] guide for more screenshots of WebScarab in action.

[[Image:WebScarab after browsing.png]]

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP subscription page], and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

You can download WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge]. Then install them likewise:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: double-click the installer jar file

A Mac OS X package of the latest version can usually be found on [http://research.corsaire.com/tools/ Corsaire's download page].

You can also try the [http://dawes.za.net/rogan/webscarab/WebScarab.jnlp Java Web Start version], which was signed by Rogan Dawes.

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyses a number of cookies to visually determine the degree of randomness and unpredictability. Note that this analysis is rather trivial, and does not do any serious checks, such as FIPS, etc.

* Scripted - operators can use BeanShell (or any other BSF supported language found on the classpath) to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server. '''NOTE''': This plugin is deprecated, and may be removed in the future. [http://www.soapui.org SOAPUI] is streets beyond anything that Webscarab can do, or will ever do, and is also a free tool.

* Extensions - automates checks for files that were mistakenly left in web server's root directory (e.g. .bak, ~, etc). Checks are performed for both, files and directories (e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Extensions for files and directories can be edited by user.

* XSS/CRLF - passive analysis plugin that searches for user-controlled data in HTTP response headers and body to identify potential CRLF injection (HTTP response splitting) and reflected cross-site scripting (XSS) vulnerabilities.

==Training Material==

Aung Khant (YGN Ethical Hacker Group, Myanmar) has created a series of WebScarab movies which can be found [http://yehg.net/lab/pr0js/training/webscarab.php here].

There are slides of the presentation "Uncovering Webscarab's Hidden Treasures", given at the OWASP EU Summit 2008, available [https://www.owasp.org/images/8/88/OWASP_EU_Summit_2008_WebScarab_treasures.ppt here].

==Future development==

Features will probably include:

* Combining the Search and Compare plugins, so that you can compare only specific responses

* Improving the fuzzer, adding ability to follow redirects, or to specify the number of threads to use. Also, adding the ability to define what is (or isn't) interesting in the fuzz results, and save only interesting conversations to the summary.

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]

Category:OWASP WebScarab Project

2008-11-07T11:27:36Z

RoganDawes: Add training material

{{OWASP Book|1416452}}

'''Welcome to the WebScarab Project'''

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

You may also be interested in testing the [[OWASP WebScarab NG Project | Next Generation of WebScarab]].

==Screenshots==

Here's the main window of WebScarab. Check the [[WebScarab Getting Started]] guide for more screenshots of WebScarab in action.

[[Image:WebScarab after browsing.png]]

==Overview==

There is no shiny red button on WebScarab, it is a tool primarily designed to be used by people who can write code themselves, or at least have a pretty good understanding of the HTTP protocol. If that sounds like you, welcome! Download WebScarab, sign up for the mailing list on the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP subscription page], and enjoy! You can read a [[WebScarab Tutorial | brief tutorial ]] to explain the basic workings.

WebScarab is designed to be a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow the developer to debug otherwise difficult problems, or to allow a security specialist to identify vulnerabilities in the way that the application has been designed or implemented.

==Download==

You can download WebScarab from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823 OWASP Source Code Center at Sourceforge]. Then install them likewise:
* Linux: <tt>java -jar ./webscarab-selfcontained-[numbers].jar</tt>
* Windows: double-click the installer jar file

A Mac OS X package of the latest version can usually be found on [http://research.corsaire.com/tools/ Corsaire's download page].

You can also try the [http://dawes.za.net/rogan/webscarab/WebScarab.jnlp Java Web Start version], which was signed by Rogan Dawes.

==Features==

A framework without any functions is worthless, of course, and so WebScarab provides a number of plugins, mainly aimed at the security functionality for the moment. Those plugins include:

* Fragments - extracts Scripts and HTML comments from HTML pages as they are seen via the proxy, or other plugins

* Proxy - observes traffic between the browser and the web server. The WebScarab proxy is able to observe both HTTP and encrypted HTTPS traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it. Various proxy plugins have also been developed to allow the operator to control the requests and responses that pass through the proxy.

* Manual intercept - allows the user to modify HTTP and HTTPS requests and responses on the fly, before they reach the server or browser.

* Beanshell - allows for the execution of arbitrarily complex operations on requests and responses. Anything that can be expressed in Java can be executed.

* Reveal hidden fields - sometimes it is easier to modify a hidden field in the page itself, rather than intercepting the request after it has been sent. This plugin simply changes all hidden fields found in HTML pages to text fields, making them visible, and editable.

* Bandwidth simulator - allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

* Spider - identifies new URLs on the target site, and fetches them on command.

* Manual request - Allows editing and replay of previous requests, or creation of entirely new requests.

* SessionID analysis - collects and analyses a number of cookies to visually determine the degree of randomness and unpredictability. Note that this analysis is rather trivial, and does not do any serious checks, such as FIPS, etc.

* Scripted - operators can use BeanShell (or any other BSF supported language found on the classpath) to write a script to create requests and fetch them from the server. The script can then perform some analysis on the responses, with all the power of the WebScarab Request and Response object model to simplify things.

* Parameter fuzzer - performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

* Search - allows the user to craft arbitrary BeanShell expressions to identify conversations that should be shown in the list.

* Compare - calculates the edit distance between the response bodies of the conversations observed, and a selected baseline conversation. The edit distance is "the number of edits required to transform one document into another". For performance reasons, edits are calculated using word tokens, rather than byte by byte.

* SOAP - There is a plugin that parses WSDL, and presents the various functions and the required parameters, allowing them to be edited before being sent to the server. '''NOTE''': This plugin is deprecated, and may be removed in the future. [http://www.soapui.org SOAPUI] is streets beyond anything that Webscarab can do, or will ever do, and is also a free tool.

* Extensions - automates checks for files that were mistakenly left in web server's root directory (e.g. .bak, ~, etc). Checks are performed for both, files and directories (e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc). Extensions for files and directories can be edited by user.

* XSS/CRLF - passive analysis plugin that searches for user-controlled data in HTTP response headers and body to identify potential CRLF injection (HTTP response splitting) and reflected cross-site scripting (XSS) vulnerabilities.

==Training Material==

Aung Khant (YGN Ethical Hacker Group, Myanmar) has created a series of WebScarab movies at
http://yehg.net/lab/pr0js/training/webscarab.php

There are slides of the presentation "Unconvering Webscarab's Hidden Treasures", given at the OWASP EU Summit 2008, available [https://www.owasp.org/images/8/88/OWASP_EU_Summit_2008_WebScarab_treasures.ppt here]

==Future development==

Features will probably include:

* Combining the Search and Compare plugins, so that you can compare only specific responses

* Improving the fuzzer, adding ability to follow redirects, or to specify the number of threads to use. Also, adding the ability to define what is (or isn't) interesting in the fuzz results, and save only interesting conversations to the summary.

==Extensibility==

As a framework, WebScarab is extensible. Each feature above is implemented as a plugin, and can be removed or replaced. New features can be easily implemented as well. The sky is the limit! If you have a great idea for a plugin, please let us know about it on the list.

==Project Contributors==

The WebScarab project is run by Rogan Dawes of Corsaire Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]

File:OWASP EU Summit 2008 WebScarab treasures.ppt

2008-11-07T11:24:45Z

RoganDawes: WebScarab's Hidden Treasures

WebScarab's Hidden Treasures

Working Session Winter of Code 2009

2008-11-01T21:00:39Z

RoganDawes: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|'''OWASP Winter of Code 2009'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|Aims to define the next OWASP Season of Code frame.
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
*[[:OWASP Summer of Code 2008|OWASP Summer of Code 2008]],
*[[:OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]],
*[[:OWASP Autumn Of Code 2006|OWASP Autumn Of Code 2006]].
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair''' [mailto:dinis.cruz(at)owasp.org '''Dinis Cruz'''], [mailto:seba(at)owasp.org '''Sebastien Deleersnyder''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary''' [mailto:paulo.coimbra(at)owasp.org '''Paulo Coimbra''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list''' [https://lists.owasp.org/mailman/listinfo/owasp-winter-of-code-2009 '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
* Define the operation model for the next OWASP Season of Code (the Winter of Code 08),
* Identify which areas should receive priority selection,
* Create 'virtual teams' from the attendees and allocate them to key projects,
* Discuss sponsoring models.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue''' [[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time''' November 4 & 7, 2008 Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model''' "Everybody is a Participant"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|Initiative
| style="width:46%; background:#C2C2C2" align="center"|OWASP Winter of Code 08 plan.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|Decision
| style="width:46%; background:#C2C2C2" align="center"|Set of projects for immediate approval (assuming the proposal is ready).
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"| Eduardo Vianna de Camargo Neves
| style="width:15%; background:#cccccc" align="center"| Conviso IT Security
| style="width:63%; background:#cccccc" align="center"| Understand how we can help the initiative and participate to continue the Positive Security project.
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|Leonardo Cavallari Militelli
| style="width:15%; background:#cccccc" align="center"|E-VAL Tecnologia
| style="width:63%; background:#cccccc" align="center"|Share feelings from other 2 season of code, discuss improvements for WoC and continue ASDR development.
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Matt Tesauro
| style="width:15%; background:#cccccc" align="center"|OWASP Live CD 2008 Project Lead
| style="width:63%; background:#cccccc" align="center"|Discuss what worked and didn't work with the SoC. Give some input on how to spread the word about OWASP's XoC's
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"| Matteo Meucci
| style="width:15%; background:#cccccc" align="center"| Minded Security, OWASP Testing Guide
| style="width:63%; background:#cccccc" align="center"| Discuss new ideas about projects. Should OWASP says which projects develop?
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"| Carlo Pelliccioni
| style="width:15%; background:#cccccc" align="center"| Symantec, OWASP Backend Security Project
| style="width:63%; background:#cccccc" align="center"| Discuss about the next OWASP sponsorship to share new ideas.
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|Christian Martorella
| style="width:15%; background:#cccccc" align="center"|Edge-Security, WebSlayer Project
| style="width:63%; background:#cccccc" align="center"|Interested in the topic
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|Eoin Keary
| style="width:15%; background:#cccccc" align="center"|Code review guide lead
| style="width:63%; background:#cccccc" align="center"|What next for the sponsored prjoects?
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|Arturo 'Buanzo' Busleiman
| style="width:15%; background:#cccccc" align="center"|Independent
| style="width:63%; background:#cccccc" align="center"|Project Leader in 07 and 08, past experience.
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|Rogan Dawes
| style="width:15%; background:#cccccc" align="center"|Corsaire
| style="width:63%; background:#cccccc" align="center"|WebScarab lead, reviewer and past participant
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|}
If needed add here more lines.

[[Category:OWASP_Working_Session]]

OWASP Working Session - Code Review Guide

2008-11-01T20:57:16Z

RoganDawes: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|'''Code Review Guide'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|TBD
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
[[:Category:OWASP Code Review Project|OWASP Code Review Project]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair''' [mailto:eoin.keary(at)owasp.org '''Eoin Keary''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary''' [mailto:name(at)name '''TBD''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list''' [https://lists.owasp.org/mailman/listinfo/owasp-codereview '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
* Discuss next version of code review guide.
* Discuss industry requirements for code review.
* Discuss academic versus practical ramifications of guide.
* Brainstorm: Ideas for integration with other projects and tools.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue''' [[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time''' November 5 & 6, 2008 Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model''' "Everybody is a Participant"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Whteboard and Pens, Projector, Coffee :)
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|
Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Develop a roadmap for the code review guide: Technologies, approaches.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Paolo Perego (aka thesp0nge)
| style="width:15%; background:#cccccc" align="center"|Spike Reply
| style="width:63%; background:#cccccc" align="center"|Owasp Orizon - Project Leader
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|David Rook
| style="width:15%; background:#cccccc" align="center"|Realex Payments
| style="width:63%; background:#cccccc" align="center"|Contributor to Code Review Guide
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Giorgio Fedon
| style="width:15%; background:#cccccc" align="center"|Minded Security
| style="width:63%; background:#cccccc" align="center"|Very interested in the topic
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"| Matteo Meucci
| style="width:15%; background:#cccccc" align="center"| Minded Security
| style="width:63%; background:#cccccc" align="center"| Interested in integrating OWASP big 4: Dev, Code Review, Testing, ADSR
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|Kuai Hinojosa
| style="width:15%; background:#cccccc" align="center"|OWASP (MSP) Chapter Leader
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|James Walden
| style="width:15%; background:#cccccc" align="center"|NKU
| style="width:63%; background:#cccccc" align="center"|OWASP Source Code Analysis Project
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|Wagner Elias
| style="width:15%; background:#cccccc" align="center"|Conviso IT Security
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|Arturo 'Buanzo' Busleiman
| style="width:15%; background:#cccccc" align="center"|Independent
| style="width:63%; background:#cccccc" align="center"|Eoin looks passionate about the subject. I want to be near! :)
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|Rogan Dawes
| style="width:15%; background:#cccccc" align="center"|Corsaire
| style="width:63%; background:#cccccc" align="center"|Have experience, would like to contribute where possible
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|}
If needed add here more lines.

[[Category:OWASP_Working_Session]]

OWASP Working Session - OWASP Tools Projects

2008-10-12T09:35:00Z

RoganDawes: update company

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|'''OWASP Tools Projects'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|TBD
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
[[:Category:OWASP Project|OWASP Tools Projects]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair''' [mailto:mark.roxberry(at)owasp.org '''Mark Roxberry''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary''' [mailto:mtesauro(at)gmail.com '''Matt Tesauro''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list''' [https://lists.owasp.org/mailman/listinfo/owasp-tools-projects '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
* Discuss documentation procedures.
* Book creation procedure.
* Review OWASP Project Assessment.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue''' [[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time''' November 4 & 7, 2008 Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model''' "Participants + Attendees"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|
Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Paulo Coimbra
| style="width:15%; background:#cccccc" align="center"|OWASP
| style="width:63%; background:#cccccc" align="center"|Has contributed to the current OWASP Assessment Criteria.
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Rogan Dawes
| style="width:15%; background:#cccccc" align="center"|Corsaire
| style="width:63%; background:#cccccc" align="center"|WebScarab lead
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|}
If needed add here more lines.

OWASP Working Session - OWASP Tools Projects

2008-10-12T09:34:25Z

RoganDawes: Add Rogan Dawes

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|'''OWASP Tools Projects'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|TBD
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
[[:Category:OWASP Project|OWASP Tools Projects]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair''' [mailto:mark.roxberry(at)owasp.org '''Mark Roxberry''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary''' [mailto:mtesauro(at)gmail.com '''Matt Tesauro''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list''' [https://lists.owasp.org/mailman/listinfo/owasp-tools-projects '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
* Discuss documentation procedures.
* Book creation procedure.
* Review OWASP Project Assessment.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue''' [[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time''' November 4 & 7, 2008 Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model''' "Participants + Attendees"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|
Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Paulo Coimbra
| style="width:15%; background:#cccccc" align="center"|OWASP
| style="width:63%; background:#cccccc" align="center"|Has contributed to the current OWASP Assessment Criteria.
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Rogan Dawes
| style="width:15%; background:#cccccc" align="center"|OWASP
| style="width:63%; background:#cccccc" align="center"|WebScarab lead
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|}
If needed add here more lines.

OWASP EU Summit 2008 Training (Courses to be Approved)

2008-10-06T15:20:49Z

RoganDawes: /* Uncovering WebScarab's Secret Treasures */

Upon detail completion and board approval courses will be moved towards the main agenda.

== Source Code Review==

'''Instructor'''

Eoin Keary and Daniel Cuthbert (TBC)

'''Duration'''

0.5 day

'''Summary'''

An introduction to secure code review from an OWASP standpoint. Covering how to approach the review, tips and leading practice on how to get the best from a source code review. A look at the OWASP tools that support the code review guide.

'''Audience'''
Anyone that would like to learn more about secure code review.

'''Table of Contents'''

TBD
'''Course Specifics'''

TBD

== Advanced Phishing and Social Engineering Training==

'''Instructor'''

Joshua Perrymon

'''Duration'''

1 day

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

This class is designed to illustrate hands-on methods used in the real world attacking the human layer. This includes a focus on spear-phishing using the newly introduced OWASP phishing framework (LUNKER). Attendees will identify target emails using a variety of methods, identify potential phish sites, create a spoofed email and send the attack all in a locally ran test environment in Vmware or LiveCD.

Upon completion of this course, attendees will have an in-depth understanding of the latest techniques used to perform these type of attacks. The class will also include additional social engineering attack methods such as impersonation, authority attacks, pre-text attacks, and much more. Advanced topics such as Email Payloads and 2nd Factor token MITM attacks will be covered as well.

1. Introduction to Social Engineering

2. Understanding the Human Aspect of Security

3. Review of aggressively vertical hacking methodology

4. Analysis of attack trending over the years (Up the OSI Model)

5. Review of public Social Engineering Attacks in the media

6. Hands on: Spear Phishing Demo using the Lunker Framework
a. Understanding the Social Engineering Scope of work
b. Setup Client Info
c. Gather Email addresses/targets
d. Identify potential phishing sites
e. Creation of spoofed emails
i. Custom footers
ii. Attack Scenarios
iii. Email header options

f. Test Environment: Review the spoofed email and phishing site

g. Send attack

h. Monitor: Discuss steps to take at this point once the users send in credentials.

i. Advanced Phishing Attacks: Recon, XSS/CSRF/Browser Exploit/Trojan payloads

j. MITM Attacks on 2-factor Authentication

k. Summary

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== OWASP ESAPI ==

'''Instructor'''

Jeff Williams, Aspect Security

'''Duration'''

1 day.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Web Services and SOA Security ==

'''Instructor'''

Dave Wichers, Aspect Security

'''Duration'''

2 days

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Advanced Web Application Security Testing ==

'''Instructor'''

Michael Coates, Aspect Security

'''Duration'''

2 days

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Uncovering WebScarab's Secret Treasures ==

'''Instructor'''

Rogan Dawes

'''Duration'''

1 day.

'''Summary'''

OWASP WebScarab has a lot of hidden features that probably no one but the author really knows about. This in depth hands on session will show delegates how to access these features, and how to use them to their full potential.

'''Audience'''

Application reviewers, developers

'''Table of Contents'''

* Using the spider
* Manual Request Transforms
* What is the XSS/CRLF plugin, and how does it work?
* Using the Fuzzer
* Comparing Responses
* Searching WebScarab history
* Exploring the Beanshell
** Writing Proxy Intercept scripts
** Writing Script Manager Scripts
** Writing other scripts

'''Course Specifics'''

Bring your own laptop

== Testing Guide Training ==

'''Instructor'''

Matteo Meucci, Giorgio Fedon.

'''Duration'''

4h.

'''Summary'''

Please enter the text here.

'''Audience'''

Software developers, security consultants, auditors.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Bring your own laptop.

== AJAX Security ==

'''Instructor'''

Brad Causey

'''Duration'''

1 Day

'''Summary'''

Additional Details and summary to follow...

'''Audience'''

Web Application Security Professionals

'''Table of Contents'''

Details to come

'''Course Specifics'''

Please bring your own laptop with your choice of web proxy and browser installed if you wish to participate. Participation is optional.

== Course Name {template} ==

'''Instructor'''

Please enter the text here.

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

OWASP EU Summit 2008 Training (Courses to be Approved)

2008-09-18T07:27:53Z

RoganDawes: Add WebScarab session

The courses listed on this page are to be approved by OWASP Board.

== Source Code Review==

'''Instructor'''

Eoin Keary and Daniel Cuthbert

'''Duration'''

Please enter the text here

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Advanced Phishing and Social Engineering Training==

'''Instructor'''

Joshua Perrymon

'''Duration'''

1 day

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

This class is designed to illustrate hands-on methods used in the real world attacking the human layer. This includes a focus on spear-phishing using the newly introduced OWASP phishing framework (LUNKER). Attendees will identify target emails using a variety of methods, identify potential phish sites, create a spoofed email and send the attack all in a locally ran test environment in Vmware or LiveCD.

Upon completion of this course, attendees will have an in-depth understanding of the latest techniques used to perform these type of attacks. The class will also include additional social engineering attack methods such as impersonation, authority attacks, pre-text attacks, and much more. Advanced topics such as Email Payloads and 2nd Factor token MITM attacks will be covered as well.

1. Introduction to Social Engineering

2. Understanding the Human Aspect of Security

3. Review of aggressively vertical hacking methodology

4. Analysis of attack trending over the years (Up the OSI Model)

5. Review of public Social Engineering Attacks in the media

6. Hands on: Spear Phishing Demo using the Lunker Framework
a. Understanding the Social Engineering Scope of work
b. Setup Client Info
c. Gather Email addresses/targets
d. Identify potential phishing sites
e. Creation of spoofed emails
i. Custom footers
ii. Attack Scenarios
iii. Email header options

f. Test Environment: Review the spoofed email and phishing site

g. Send attack

h. Monitor: Discuss steps to take at this point once the users send in credentials.

i. Advanced Phishing Attacks: Recon, XSS/CSRF/Browser Exploit/Trojan payloads

j. MITM Attacks on 2-factor Authentication

k. Summary

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Web server/services hardening using SELinux ==

'''Instructor'''

Pavol Luptak

'''Duration'''

1 day

'''Summary'''

Security-Enhanced Linux (SELinux) is a FLASK implementation integrated in the Linux kernel with a number of utilities designed to provide mandatory access controls (MAC) through the use of Linux Security Modules (LSM) in the Linux kernel. SELinux generally supports many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security.

A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).

This training provides basic concepts of SELinux, its differences to classical UNIX/Linux systems, describe security advantages of mandatory access control policies and teach how to effectively and rapidly configure a fully functional LAMP environment on SELinux system.

'''Audience'''

Security consultants, system administators, programmers focused on system security

'''Table of Contents'''

1. SELinux history

2. Unix/Linux DAC (Discretionary Access Control) and its problems

3. MAC (Mandatory Access Control)

4. Advantages of using MAC

5. DTE (Domain Type Enforcement) model

6. RBAC (Roles Based Access Control) model

7. MLS (Multi Level Security) model

8. SELinux FLASK Architecture

9. SELinux policy (EXERCISE)

10. File System Security Contexts (EXERCISE)

11. SELinux Object Classes and Permissions

12. TE (Type Enforcement) Rules (Attributes, Type Declaration, Type Transitions, Domain Type Transitions, Object Labeling Transitions, Access Vectors)

13. Understanding AVC, log messages

14. audit2allow and audit2why (EXERCISE)

15. SELinux Troubleshoot Tool (EXERCISE)

16. Auditing and Auditing tools

17. Policy Macros

18. Backtracking rule (EXERCISE)

19. SELinux Users, Roles, MLS Levels

20. Strict Policy

21. Targeted Policy

22. SELinux Booleans and their use for Apache web server (EXERCISE)

23. Files and Directories in Targeted Policy, common SELinux Macros (EXERCISE)

24. Analyzing Example Policy - apache.te (EXERCISE)

25. Assigning Object and Process Types

26. SELinux Booting

27. Copying and moving files, checking security contexts, relabeling a file and directory's security context (EXERCISE)

28. Policy core utilities

29. Managing File Labeling, Relabeling a File System (EXERCISE)

30. SELinux Administrator GUI (EXERCISE)

31. SELinux Modules (EXERCISE)

32. Hardening existing LAMP environments using SELinux (EXERCISE)

33. Writing New Policy for a Daemon (EXERCISE for clever students)

'''Course Specifics'''

Bring your own laptop. Each student will have own SELinux virtual machine for his experiments.

== Secure Programming with Java ==

'''Instructor'''

Lucas C. Ferreira

'''Duration'''

1 Day

'''Summary'''

This training class will present best practices of secure programming in the Java language. It includes Java specific practices (i.e. how to avoid problems that arise from the compilation of Java source code to the bytecode language used by the JVM) and practices that may arise in other programming languages (with examples in Java). Some tools that may be used to verify the security of Java code and systems will be shown.

The topics include a quick overview of the OWASP Top 10, in order to contextualize the practices presented, and several best practices aimed at the different software layers. At the presentation layer, we focus on input validation, access control issues and dealing with exceptions. At the business objects layer, the practices deal with cloning and serialization issues. Practices to prevent command injection are presented at the persistence layer. Practices that should be used throughout all the software are also presented, including input data validation, class and method visibility, using and storing secrets, dealing with inner classes, overflows and boxing, and object initialization.

'''Audience'''

Java web application developers. This training requires basic understanding of web applications and an intermediate level of proficiency in the Java language and Object Oriented concepts. People with interest in other OO languages may also benefit from this training, but specific techniques, examples and tools used are targeted to Java.

'''Table of Contents'''

# OWASP Top 10 - quick overview
# Secure Programming Best Practices
## Presentation layer
### Preventing cross-site scripting
### Access control
### Request validation
### Error treatment
## Business object layer
### Cloning and serialization issues
## Persistence layer
### Command injection issues
### Database access users and permissions
### file manipulation
## Infra-structure layer
### J2EE container-related best practices
### Native method issues
### SSL and encryption
## Practices for all software layers
### Data validation
### Garbage collection issues
### Classes and method scoping
### Use of secrets
### Inner class issues
### Over/underflow and boxing issues
# Tools
## Code review tool
## Data flow tool
## Pen-testing tool

'''Course Specifics'''

Due to the lack of time, we will only show tool usage (no practical exercises with the audience).

== Advanced Web Application Penetration Testing ==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Leading, Planning, and Executing an Application Security Initiative==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Foundations of Web Application Security==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Secure Coding .NET Web Applications==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Building Secure Rich Internet Applications==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Web Application Security - Advanced Attacks and Defense==

'''Instructor'''

Aspect Security

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== What Developers Should Know on Web Application Security==

'''Instructor'''

Sebastien Deleersnyder and Martin Knobloch

'''Duration'''

4 h
To be scheduled on Wednesday afternoon Nov 5.

'''Summary'''

Application security is an essential component of any successful project; this includes web applications, open source PHP applications, web services and proprietary business web sites.
Web application security education and awareness is needed throughout the entire development and deployment organization. Each area and level of development or deployment organizations have specific needs and requirements regarding web application security education. A manager needs other information than a security professional or developer. Novices to the profession require other training than people with several years of experience.

The OWASP Education project aims to provide in building blocks of web application security information. These modules can be combined together in education tracks targeting different audiences.
This Education Track provides in a 4 hour session covering what developers should know on web application security. It starts with an explanation of web application security and why it is important. Then the OWASP Top 10 is used to explain the nastiest vulnerabilities and how these can be prevented or re mediated. A secure coding initiative must deal with all stages of a program’s life cycle. Secure web applications are only possible when a secure SDLC is used. The SDLC is explained from the standpoint of people, processes and tools. Particularly for developers good secure development practices are covered in a separate topic. Finally the track finishes with an exhaustive list of web application security resources for web application developers.

'''Audience'''

Web application developers who are unaware there are security issues with contemporary web applications. No prior knowledge of web application security is assumed nor necessary. This track is independent of the coding language or web frameworks used; like PHP, JSF, Java EE or .NET. We must realize that web application developers are only one link - albeit an important one - of the chain that represents the security of a web application. This track aims to make that link as secure as possible, given the constraint of 4 hours. Another important aspect is that web application security should be tailored to the risk profile of an organization and the specific development environment of that organization.

'''Table of Contents'''

The challenge is to cover web application security in 4 hours to a web application developer. This is presented in such a way that the developers will be able to recognize and correct web application vulnerabilities in their projects.

* [[Education Module Why WebAppSec Matters|Why WebAppSec matters]] (20 min) ([http://www.owasp.org/images/5/58/Education_Module_Why_WebAppSec_Matters.ppt direct link])
:This part is the introduction of the track. It identifies the current security problems with web applications. During the introduction a definition of web application security is given. Trends that are influencing the current state of web application insecurity are also explained.
:*What goes wrong
:*WebAppSec Defined
:*Current trends
* [[Education_Module_OWASP_Top_10_Introduction_and_Remedies|OWASP Top 10 Introduction & Remedies]] (90 min) ([http://www.owasp.org/images/b/b8/Education_Module_OWASP_Top_10_Introduction_and_Remedies.ppt direct link])
:The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities.
:*[[Education Module Cross Site Scripting (XSS)|Cross Site Scripting (XSS)]]
:*Injection Flaws
:*Malicious File Execution
:*Insecure Direct Object Reference
:*Cross Site Request Forgery (CSRF)
:*Information Leakage and Improper Error Handling
:*Broken Authentication and Session Management
:*Insecure Cryptographic Storage
:*Insecure Communications
:*Failure to Restrict URL Access
*[[Education Module Embed within SDLC|Embed within SDLC]] (People, Processes & Tools) (20 min) ([http://www.owasp.org/images/f/f2/Education_Module_Embed_within_SDLC.ppt direct link])
:There is no silver bullet when it comes to securing web applications. This problem has to be addressed from different angles, covering the involved actors, processes: development as well as deployment and Technologies.
:*People Awareness and Education
:*Development WebAppSec Controls
:*Deployment WebAppSec Controls
:*WebAppSec Tools
*[[Education Module Good Secure Development Practices|Good Secure Development Practices]] (70 min) ([http://www.owasp.org/images/5/57/Education_Module_Good_Secure_Development_Practices.ppt direct link])
:Next to the Top 10 remedies this module provides some good secure development practices from the OWASP Guide, covering e.g.
:*Validating User Input
:*Authentication
:*Authorization
:*Session Management
:*Using Interpreters
:*Crypto
:*Catching Errors
:*File System
:*Configuration
:*Web 2.0
*[[Education Module Testing for Vulnerabilities|Testing for Vulnerabilities]] (20 min) ([http://www.owasp.org/images/4/49/Education_Module_Testing_for_Vulnerabilities.ppt direct link])
:One important aspect is to test for application vulnerabilities. During this short module an introduction is provided together with some WebGoat test cases.
:*Testing for application vulnerabilities
:*The OWASP Testing Guide
:*WebGoat demonstrated
*[[Education Module Good WebAppSec Resources|Good WebAppSec Resources]] (not limited to OWASP) (10 min) ([http://www.owasp.org/images/f/fe/Education_Module_Good_WebAppSec_Resources.ppt direct link])
:This 4 hour education track in only the beginning of your journey. Web application security is a moving target. New vulnerabilities and threats are discovered regularly. Web application security controls are becoming mature. The following resources should provide you with enough pointers to serve both as reference and for further research.
:*Hard Copy
:*Web Sites
:*Mailing lists
:*Blogs
*Roundup (10 min)

[[Category:OWASP Education Project]]

'''Course Specifics'''

No specific prerequisites.

== Linux Software Exploitation ==

'''Instructor'''

Nam Nguyen

'''Duration'''

2 days

'''Summary'''

This course is a primer into software exploitation on the Linux environment. The course assumes only basic understanding of the Linux commands, and C programming with the standard library. It explains the computer architecture, assembly language then moves on to three basic classes of security bug: buffer overflow, format string, and race condition and methods to take advantage of them. Throughout the course, various examples are introduced with increasing difficulty so that participants will naturally realize the art of software exploitation for themselves.

This course does not discuss about shell coding. Except on one example where provided shell code is used as an illustration, all other challenges require only good analysis and calculation.

The course is conducted as a workshop with heavy interaction between participants and instructor. There will not be any presentation slide. Participants are to take note during the course.

'''Audience'''

Software developers, system administrators, security engineers with some experience in Linux and C programming.

'''Table of Contents'''

# Computer architecture
# Assembly language
# Buffer overflow
# Format string
# Race condition
# Techniques
## Overwrite critical variable
## Overwrite return address
## Return to .text
## Return to libc
## Overwrite .dtors
## Overwrite .got
## Overwrite .bss, functors
## By pass Advanced Space Layout Randomization
# Tools of the trade: IDA, GDB, and Python

'''Course Specifics'''

Bring your own laptop with VMWare Player or equivalent. An VM image will be provided.

== Classic ASP Security using OWASP tools ==

'''Instructor'''

Juan Carlos Calderon

'''Duration'''

1 day

'''Summary'''

Classic ASP 2.0 and 3.0 applications are still largely used as this technology is more than 10 years old and was largely used. there are thousands of sites on the wild that need guidance on the security arena. This is where OWASP can come up and provide help for “making the Web a better place”.

'''Audience'''

Classic ASP Developers, Application Architects, people with basic ASP knowledge?

'''Table of Contents'''

*Secure programming on ASP using [[ESAPI|OWASP ESAPI]]
*Auditing ASP code with [[:Category:OWASP_Code_Review_Project|Code Review Project]] checklist
*Implementing [[:Category:OWASP_Stinger_Project|OWASP Stinger]] protection for Classic ASP
*ASP specific Best Practices to protect ASP applications.

'''Course Specifics'''

None. Keep posted for changes on the table of contents and course specifics.

== Course Name Uncovering WebScarab's Secret Treasures ==

'''Instructor'''

Rogan Dawes

'''Duration'''

1 day.

'''Summary'''

OWASP WebScarab has a lot of hidden features that probably no one but the author really knows about. This in depth hands on session will show delegates how to access these features, and how to use them to their full potential.

'''Audience'''

Application reviewers, developers

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Bring your own laptop

== Course Name {template} ==

'''Instructor'''

Please enter the text here.

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

== Course Name {template} ==

'''Instructor'''

Please enter the text here.

'''Duration'''

Please enter the text here.

'''Summary'''

Please enter the text here.

'''Audience'''

Please enter the text here.

'''Table of Contents'''

Please enter the text here.

'''Course Specifics'''

Please enter the text here. (i.e. bring your own laptop)

OWASP EU Summit 2008 Paid Participants

2008-09-09T10:32:12Z

RoganDawes:

== Provisory list of 'expenses paid' participants ==

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|'''PROJECTED CONFERENCE PAID ATTENDEES AND/OR SPEAKERS - NEEDS OWASP BOARD CONFIRMATION'''
|-
| style="width:20%; background:#b3b3b3" align="center"|'''NAME'''
| style="width:40%; background:#b3b3b3" align="center"|'''POSITION/REASON OF ATTENDANCE'''
| style="width:20%; background:#b3b3b3" align="center"|'''COUNTRY'''
| style="width:20%; background:#b3b3b3" align="center"|'''DEPARTURE (AIRPORT/CITY)'''
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP BOARD MEMBERS & EMPLOYEES'''
|-
| style="width:20%; background:#cccccc" align="center"|Jeff Williams
| style="width:40%; background:#cccccc" align="center"|Board, Chair, Wiki, Management
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Washington, D.C.
|-
| style="width:20%; background:#cccccc" align="center"|Dave Wichers
| style="width:40%; background:#cccccc" align="center"|Board, Conferences, Financials
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Washington, D.C.
|-
| style="width:20%; background:#cccccc" align="center"|Dinis Cruz
| style="width:40%; background:#cccccc" align="center"|Board, Firehose of Ideas and Money spender
| style="width:20%; background:#cccccc" align="center"|UK
| style="width:20%; background:#cccccc" align="center"|London
|-
| style="width:20%; background:#cccccc" align="center"|Tom Brennan
| style="width:40%; background:#cccccc" align="center"|Board, OWASP Governance
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|New York, NY
|-
| style="width:20%; background:#cccccc" align="center"|Sebastien Deleersnyder
| style="width:40%; background:#cccccc" align="center"|Board, OWASP Chapters and Projects
| style="width:20%; background:#cccccc" align="center"|Belgium
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Paulo Coimbra
| style="width:40%; background:#cccccc" align="center"|Employee, Project Manager
| style="width:20%; background:#cccccc" align="center"|UK
| style="width:20%; background:#cccccc" align="center"|London
|-
| style="width:20%; background:#cccccc" align="center"|Kate Hartmann
| style="width:40%; background:#cccccc" align="center"|Employee, Operations Director
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Washington, D.C.
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP SUMMER OF CODE 2008 PROJECT LEADERS & REVIEWERS'''
|-
| style="width:20%; background:#cccccc" align="center"|Achim Hoffmann
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Skavenger Project, OWASP w3af Project
| style="width:20%; background:#cccccc" align="center"|Germany
| style="width:20%; background:#cccccc" align="center"|Frankfurt or Munich
|-
| style="width:20%; background:#cccccc" align="center"|Alexander Fry
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Source Code Review OWASP Projects OWASP Teachable Static Analysis Workbench OWASP WeBekci Project
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Arshan Dabirsiaghi
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP AntiSamy Project
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Baltimore, MD
|-
| style="width:20%; background:#cccccc" align="center"|Andrew Petukhov
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Access Control Rules Tester Project
| style="width:20%; background:#cccccc" align="center"|Russia
| style="width:20%; background:#cccccc" align="center"|Moscow
|-
| style="width:20%; background:#cccccc" align="center"|Dmitry Kozlov
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Teachable Static Analysis, OWASP Application Security Tool Benchmarking Environment and Site Generator Refresh Project
| style="width:20%; background:#cccccc" align="center"|Russia
| style="width:20%; background:#cccccc" align="center"|Moscow
|-
| style="width:20%; background:#cccccc" align="center"|Arturo Alberto Busleiman
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Enigform and mod_Openpgp
| style="width:20%; background:#cccccc" align="center"|Argentina
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Carlo Pelliccioni
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Backend Security Project
| style="width:20%; background:#cccccc" align="center"|Italy
| style="width:20%; background:#cccccc" align="center"|Rome (FCO)
|-
| style="width:20%; background:#cccccc" align="center"|Deb, LX Studios
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Book Cover & Sleeve Design, OWASP Individual & Corporate Member Packs, Conference Attendee Packs
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Eduardo Vianna de Camargo Neves
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Positive Security
| style="width:20%; background:#cccccc" align="center"|Brazil
| style="width:20%; background:#cccccc" align="center"|Curitiba (CWB)
|-
| style="width:20%; background:#cccccc" align="center"|Wagner Elias
| style="width:40%; background:#cccccc" align="center"|Reviwer, OWASP Positive Security
| style="width:20%; background:#cccccc" align="center"|Brazil
| style="width:20%; background:#cccccc" align="center"|São Paulo(GRU)
|-
| style="width:20%; background:#cccccc" align="center"|Eoin Keary
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Code Review Guide, Chapter Leader
| style="width:20%; background:#cccccc" align="center"|Ireland
| style="width:20%; background:#cccccc" align="center"|Dublin (DUB)
|-
| style="width:20%; background:#cccccc" align="center"|Esteban Ribicic
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Backend Security Project OWASP Classic ASP Security Project OWASP AntiSamy .NET OWASP Interceptor Project - 2008 Update
| style="width:20%; background:#cccccc" align="center"|Croatia
| style="width:20%; background:#cccccc" align="center"|Wien
|-
| style="width:20%; background:#cccccc" align="center"|Fabio Cerullo
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Internationalization Guidelines Project OWASP Spanish Project
| style="width:20%; background:#cccccc" align="center"|Ireland
| style="width:20%; background:#cccccc" align="center"|Dublin (DUB)
|-
| style="width:20%; background:#cccccc" align="center"|Frederick Donovan
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Application Security Desk Reference (ASDR)
| style="width:20%; background:#cccccc" align="center"|United States
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Heiko Webers
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Ruby on Rails Security Project
| style="width:20%; background:#cccccc" align="center"|Germany
| style="width:20%; background:#cccccc" align="center"|Frankfurt
|-
| style="width:20%; background:#cccccc" align="center"|Anthony Shireman
| style="width:40%; background:#cccccc" align="center"|Project reviewer, OWASP Ruby on Rails Security Project
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Portland, OR (PDX)
|-
| style="width:20%; background:#cccccc" align="center"|Juan Carlos Calderon
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Internationalization Guidelines OWASP Spanish Project OWASP Classic ASP Security Project
| style="width:20%; background:#cccccc" align="center"|Mexico
| style="width:20%; background:#cccccc" align="center"|MMAS - Aguascalientes, Mexico
|-
| style="width:20%; background:#cccccc" align="center"|Justin Derry
| style="width:40%; background:#cccccc" align="center"|Chapter leader & Project Leader, OWASP Interceptor Project
| style="width:20%; background:#cccccc" align="center"|Sydney Australia
| style="width:20%; background:#cccccc" align="center"|Sydney Australia
|-
| style="width:20%; background:#cccccc" align="center"|Kevin Fuller
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Testing Guide v3 OWASP SQL Injector Benchmarking Project (SQLiBENCH)
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Sacramento Ca
|-
| style="width:20%; background:#cccccc" align="center"|Leonardo Cavallari Militelli
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Application Security Desk Reference (ASDR)
| style="width:20%; background:#cccccc" align="center"|Brazil
| style="width:20%; background:#cccccc" align="center"|Sao Paulo (GRU)
|-
| style="width:20%; background:#cccccc" align="center"|Mark Roxberry
| style="width:40%; background:#cccccc" align="center"|Leader, OWASP .NET Project
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Matt Tesauro
| style="width:40%; background:#cccccc" align="center"|Project Leader, OWASP Live CD 2008
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Austin, TX or Dallas, TX
|-
| style="width:20%; background:#cccccc" align="center"|Matteo Meucci
| style="width:40%; background:#cccccc" align="center"|Project Leader, OWASP Testing Guide
| style="width:20%; background:#cccccc" align="center"|Italy
| style="width:20%; background:#cccccc" align="center"|Rome
|-
| style="width:20%; background:#cccccc" align="center"|Matthias Rohr
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Skavenger Project
| style="width:20%; background:#cccccc" align="center"|Germany
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Michael Coates
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP AppSensor
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Chicago
|-
| style="width:20%; background:#cccccc" align="center"|Nam Nguyen
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Testing Guide v3, Python Static Analysis, OWASP Education
| style="width:20%; background:#cccccc" align="center"|Vietnam
| style="width:20%; background:#cccccc" align="center"|Ho Chi Minh City
|-
| style="width:20%; background:#cccccc" align="center"|P.Satish Kumar
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Code Review Guide
| style="width:20%; background:#cccccc" align="center"|India
| style="width:20%; background:#cccccc" align="center"|Hyderabad/Mumbai/Chennai
|-
| style="width:20%; background:#cccccc" align="center"|Paolo Perego
| style="width:40%; background:#cccccc" align="center"|Project Leader, OWASP Orizon Project
| style="width:20%; background:#cccccc" align="center"|Italy
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Parvathy Iyer
| style="width:40%; background:#cccccc" align="center"|OWASP Corporate Application Security Guide
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Newark (New Jersey)or Newyork (Newyork city)
|-
| style="width:20%; background:#cccccc" align="center"|Pierre Parrend
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP OpenSign Server Project OWASP Application Security Verification Standard
| style="width:20%; background:#cccccc" align="center"|France
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Stephen Craig Evans
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Securing WebGoat using ModSecurity
| style="width:20%; background:#cccccc" align="center"|Singapore
| style="width:20%; background:#cccccc" align="center"|Singapore
|-
| style="width:20%; background:#cccccc" align="center"|Jason Li
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP JSP Testing Tool
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Baltimore
|-
| style="width:20%; background:#cccccc" align="center"|Gandhi Aryavalli Sriranga Narasimha
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Application Security Desk Reference (ASDR)
| style="width:20%; background:#cccccc" align="center"|India
| style="width:20%; background:#cccccc" align="center"|Bangalore
|-
| style="width:20%; background:#cccccc" align="center"|Rodrigo Marcos
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP Internationalization Guidelines Project OWASP Spanish Project
| style="width:20%; background:#cccccc" align="center"|UK
| style="width:20%; background:#cccccc" align="center"|London
|-
| style="width:20%; background:#cccccc" align="center"|Marcin Wielgoszewski
| style="width:40%; background:#cccccc" align="center"|Reviewer, OWASP AntiSamy.NET
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|New York, NY
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP SUMMER OF CODE 2008 SPECIAL PROJECT CONTRIBUTORS'''
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP SUMMER OF CODE 2008/LOGISTICS'''
|-
| style="width:20%; background:#cccccc" align="center"|Sarah Cruz
| style="width:40%; background:#cccccc" align="center"|Project leader, Graphic Design
| style="width:20%; background:#cccccc" align="center"|UK
| style="width:20%; background:#cccccc" align="center"|London
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP SPRING OF CODE 2007 PROJECT LEADERS & REVIEWERS'''
|-
| style="width:20%; background:#cccccc" align="center"|Joshua Perrymon
| style="width:40%; background:#cccccc" align="center"|Project Leader, OWASP LiveCD, OWASP Phishing Framework, Alabama Chapter Lead
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|Birmingham,AL
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP AUTUMN OF CODE 2006 PROJECT LEADERS & REVIEWERS'''
|-
| style="width:20%; background:#cccccc" align="center"|Rogan Dawes
| style="width:40%; background:#cccccc" align="center"|Project leader, WebScarab-NG
| style="width:20%; background:#cccccc" align="center"|South Africa
| style="width:20%; background:#cccccc" align="center"|Johannesburg, South Africa
|-
| style="width:20%; background:#cccccc" align="center"|Simon Roses Femerling
| style="width:40%; background:#cccccc" align="center"|Project leader, OWASP Pantera
| style="width:20%; background:#cccccc" align="center"|Spain
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
! colspan="7" align="left" style="background:white; color:black"|'''ACTIVE PROJECT LEADERS (NOT CURRENTLY PARTICIPATING ON SOC 08)'''
|-
| style="width:20%; background:#cccccc" align="center"|Alex Smolen
| style="width:40%; background:#cccccc" align="center"| Project leader, .NET ESAPI
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
! colspan="7" align="left" style="background:white; color:black"|'''ACTIVE CHAPTER LEADERS (NOT CURRENTLY PARTICIPATING ON SOC 08)'''
|-
| style="width:20%; background:#cccccc" align="center"|Antti Laulajainen
| style="width:40%; background:#cccccc" align="center"|Chapter leader, Helsinki
| style="width:20%; background:#cccccc" align="center"|Finland
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Steve Antoniewicz
| style="width:40%; background:#cccccc" align="center"|Chapter Board Member, NY/NJ Metro
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Kuai Hinojosa
| style="width:40%; background:#cccccc" align="center"|Chapter leader, Twin-Cities
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Jim Manico
| style="width:40%; background:#cccccc" align="center"|Chapter leader/founder, Hawaii
| style="width:20%; background:#cccccc" align="center"|Hawaii, USA
| style="width:20%; background:#cccccc" align="center"|Anahola, Island of Kauai
|-
| style="width:20%; background:#cccccc" align="center"|Rex Booth
| style="width:40%; background:#cccccc" align="center"|Chapter leader, Washington DC
| style="width:20%; background:#cccccc" align="center"|USA
| style="width:20%; background:#cccccc" align="center"|?
|-
| style="width:20%; background:#cccccc" align="center"|Andrzej Targosz
| style="width:40%; background:#cccccc" align="center"|Chapter leader, Poland
| style="width:20%; background:#cccccc" align="center"|Poland
| style="width:20%; background:#cccccc" align="center"|Cracow
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
! colspan="7" align="left" style="background:white; color:black"|'''SIGNIFICANT PAST OWASP CONTRIBUTOR (THAT IS NOT ALREADY COVERED BY ONE OF THE ABOVE CATEGORIES)'''
|-
| style="width:20%; background:#cccccc" align="center"|David Rook
| style="width:40%; background:#cccccc" align="center"|Code Review Guide Contributor, Irish Chapter Contributor
| style="width:20%; background:#cccccc" align="center"|Ireland
| style="width:20%; background:#cccccc" align="center"|Dublin (DUB)
|-
! colspan="7" align="left" style="background:white; color:black"|'''OWASP NON-INDIVIDUAL MEMBERS'''
|-
| style="width:20%; background:#cccccc" align="center"|Name
| style="width:40%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"|
|-
|}

User:RoganDawes

2008-07-10T16:51:10Z

RoganDawes: New page: This page contains some information about Rogan Dawes === OWASP Projects === Rogan is the lead developer of the OWASP WebScarab and WebScarab-NG projects. He is also a contributor to th...

This page contains some information about Rogan Dawes

=== OWASP Projects ===

Rogan is the lead developer of the OWASP WebScarab and WebScarab-NG projects.
He is also a contributor to the OWASP ESAPI project.
He has made substantial contributions to the OWASP WebGoat project.

OWASP EU Summit 2008

2008-07-02T18:03:16Z

RoganDawes:

(WORK IN PROGRESS /UNDER DISCUSSION)
== UPDATES ==
*[[OWASP EU Summit 2008 - updates|'''OWASP EU Summit 2008 - updates''']]

== What: OWASP Summit, a conference about OWASP and for OWASP's community ==
=== When: 4 to 7 Nov 2008 (4 & 5: Meetings and Training, 6 & 7: Conference) ===
=== Where: Portugal ===
Faro or Lisbon
=== Organization===
Paulo Coimbra and Dinis Cruz
== Agenda ==
Theme: Present OWASP's projects, community and activities ..... '....Connecting the dots.... "

'''Day 1 & 2'''
*Training sessions (similar to what happens at the moment at the other OWASP conferences)
*OWASP Working Group sessions (1/2 day each) on:
** OWASP Governance, "What is OWASP's position on ...." & Action Plan for 2009
** ESAPI
** Browser Security
** OWASP Top 10 2009

'''Day 3 & 4 Agenda:'''
* Presentations from AoC, SpoC and SoC Participants
* Presentations from 'Release' Quality OWASP projects (not included in the list above) or Key OWASP projects (like ESAPI)
* Presentations about OWASP : How it works, Financial reports, OotM (OWASP on the Move), new project management guidelines, local chapter finances, OWASP governance
* Presentation from Chapter leaders on the activities developed on their project
* Discussion on next steps for OWASP and focus of next OWASP financial investment plans

Other ideas:

* vote on 6th OWASP board member (Candidates to Apply)

== other details==

'''Projected Attendees:450 '''
* 200 with some (or all) expenses covered by OWASP
** 33 SoC participants
** 70 SoC reviewers
** 10 SoC Collaborators
** 15 AoC & SpoC participants
** 15 Chapter Leaders
** 8 OWASP Board & Employees
** 49 OWASP non-individual members (2x per 9k Corporate? 1x for the others?)

=== Financial details ===
'''Expenses'''
* Accommodation & meals: 80,000 USD = 400 USD per person (200x) for 3 nights accommodation and 5 meals (3 dinners and 2 lunches)
* Flights & Trains : 70,000 USD

'''Revenue sources'''
* Tickets (for the 250 non 'OWASP invited' attendees)
* Training Sessions
* Conference sponsors

== Participants ==
=== OWASP Board members & employees ===
* Jeff Williams
* Dave Wichers
* Dinis Cruz
* Tom Brennan
* Sebastien Deleersnyder
* Paulo Coimbra
* Kate Hartmann (to be confirmed)
* Alison McNamee (to be confirmed)
* Larry Casey (to be confirmed)

=== Summer of Code 08 Participants & Reviewers ===
* (please add your name in the following format)
* OWASP Classic ASP Security Project
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Internationalization Guidelines
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Spanish Project Reviewer Esteban Ribicic
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Ruby on Rails Security Project Leader Heiko Webers from Germany
* OWASP Code Review Guide Lead - Eoin Keary - Ireland
* OWASP Enigform and mod_Openpgp - Arturo Alberto Busleiman (a.k.a Buanzo) - Argentina
* OWASP AppSensor - Michael Coates - United States
* OWASP ASDR - Leonardo Cavallari Militelli - Brazil
*OWASO Corporate Application security guide- Parvathy Iyer- USA
* OWASP Backend Security Project - Carlo Pelliccioni - Italy

=== Winter of Code 07 Participants (Completed Projects) ===
* (please add your name)
* {Project} {Name} {Origin Country}

=== Autumn of Code 06 Participants ===
* (please add your name)
* {Project} {Name} {Origin Country}

* WebScarab-NG, Rogan Dawes, South Africa
* OWASP Pantera, Simon Roses Femerling, Spain

=== Active Chapter Leaders ===
* (please add your name in the following format)
* {Chapter} {Role} {Name} {Origin Country}
* NY/NJ Metro Board Member - Steve Antoniewicz, USA

=== Active Project Leaders (not currently participating on SoC 08)===
* (please add your name in the following format)
* {Project} {Role} {Name} {Origin Country}

=== Significant Past OWASP contributor (that is not already covered by one of the above categories) ===
* (please add your name in the following format)
* {Project/Chapter} {Role} {Name} {Origin Country}

=== Logistic and Support team ===
* Summit Graphic Design + Summit organization + on-site logistics support, Sarah Cruz, UK (London)

OWASP WebScarab Differences (Classic vs NG)

2008-04-24T16:25:05Z

RoganDawes: update the list of differences

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG now also has the Transcoder functionality, implemented as a non-modal dialog. It is intended to also implement "right-click" menus to perform various transcoding operations "in-place" in arbitrary text fields.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy, Manual Request and WebServices plugins.

Some features of the Proxy plugin remain to be ported:
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is partially completed. Currently it is sufficient to access the WebGoat web service, but it doesn't support complex types. This functionality could easily be added if desired.

==HTTP Protocol support==

WebScarab-classic has support for authentication to servers using SSL client certificates (including those stored on a smart card), as well as using NTLM. NG does not currently support SSL client certificates at all. NTLM should be supported through the Apache HTTPClient library, but this has not been tested.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

==Execution==

WebScarab NG is currently only executable via Java WebStart, which is likely to pose a problem for certain folk. An alternate packaging has been created, using the Maven onejar plugin, which packages all the required jars into a subdirectory of the "onejar", and provides a specialised classloader to allow Java to access the contents of those jars.

[[Category:OWASP WebScarab Project]]
[[Category:OWASP WebScarab NG Project]]

OWASP WebScarab Differences (Classic vs NG)

2008-02-06T15:05:10Z

RoganDawes: Http protocol support

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG now also has the Transcoder functionality, implemented as a modal dialog. It is intended to also implement "right-click" menus to perform various transcoding operations "in-place" in arbitrary text fields.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy, Manual Request and WebServices plugins.

Some features of the Proxy plugin remain to be ported:
* Ability to specify regexes for URL's (not) to be intercepted
* Ability to specify a regex for conversations that should not be stored
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is partially completed. Currently it is sufficient to access the WebGoat web service, but it doesn't support complex types. This functionality could easily be added if desired.

==HTTP Protocol support==

WebScarab-classic has support for authentication to servers using SSL client certificates (including those stored on a smart card), as well as using NTLM. NG does not currently support SSL client certificates at all. NTLM should be supported through the Apache HTTPClient library, but this has not been tested.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

==Execution==

WebScarab NG is currently only executable via Java WebStart, which is likely to pose a problem for certain folk. An alternate packaging has been created, using the Maven onejar plugin, which packages all the required jars into a subdirectory of the "onejar", and provides a specialised classloader to allow Java to access the contents of those jars.

[[Category:OWASP WebScarab Project]]
[[Category:OWASP WebScarab NG Project]]

OWASP WebScarab Differences (Classic vs NG)

2008-01-25T16:58:40Z

RoganDawes:

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG now also has the Transcoder functionality, implemented as a modal dialog. It is intended to also implement "right-click" menus to perform various transcoding operations "in-place" in arbitrary text fields.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy, Manual Request and WebServices plugins.

Some features of the Proxy plugin remain to be ported:
* Ability to specify regexes for URL's (not) to be intercepted
* Ability to specify a regex for conversations that should not be stored
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is partially completed. Currently it is sufficient to access the WebGoat web service, but it doesn't support complex types. This functionality could easily be added if desired.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

==Execution==

WebScarab NG is currently only executable via Java WebStart, which is likely to pose a problem for certain folk. An alternate packaging has been created, using the Maven onejar plugin, which packages all the required jars into a subdirectory of the "onejar", and provides a specialised classloader to allow Java to access the contents of those jars.

[[Category:OWASP WebScarab Project]]
[[Category:OWASP WebScarab NG Project]]

OWASP WebScarab Differences (Classic vs NG)

2008-01-25T16:56:32Z

RoganDawes: Status update

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG does not yet have the Transcoder functionality.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy, Manual Request and WebServices plugins.

Some features of the Proxy plugin remain to be ported:
* Ability to specify regexes for URL's (not) to be intercepted
* Ability to specify a regex for conversations that should not be stored
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is partially completed. Currently it is sufficient to access the WebGoat web service, but it doesn't support complex types. This functionality could easily be added if desired.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

==Execution==

WebScarab NG is currently only executable via Java WebStart, which is likely to pose a problem for certain folk. An alternate packaging has been created, using the Maven onejar plugin, which packages all the required jars into a subdirectory of the "onejar", and provides a specialised classloader to allow Java to access the contents of those jars.

[[Category:OWASP WebScarab Project]]
[[Category:OWASP WebScarab NG Project]]

Category:OWASP WebGoat Project

2008-01-14T09:31:06Z

RoganDawes: /* Newest Release */

[[Image:Webgoat-xss lesson.jpg|thumb|300px|right|WebGoat in action]]
'''WebGoat''' is a deliberately insecure J2EE web application maintained by [http://www.owasp.org 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.

Why the name "WebGoat"? Developers should not feel bad about not knowing security. Even the best programmers make security errors. What they need is a scapegoat, right? ''Just blame it on the 'Goat''!

'''To get started, read the [[WebGoat User and Install Guide Table of Contents|WebGoat User and Install Guide]]'''

==Goals==

Web application security is difficult to learn and practice. Not many people have full blown web applications like online book stores or online banks that can be used to scan for vulnerabilities. In addition, security professionals frequently need to test tools against a platform known to be vulnerable to ensure that they perform as advertised. All of this needs to happen in a safe and legal environment. Even if your intentions are good, we believe you should never attempt to find vulnerabilities without permission.

The primary goal of the WebGoat project is simple: ''create a de-facto interactive teaching environment for web application security''. In the future, the project team hopes to extend WebGoat into becoming a security benchmarking platform and a Java-based Web site Honeypot.

Check out the project [[OWASP WebGoat Project Roadmap|roadmap]] and find some tasks that you can help with right away.

==Download==

You can download WebGoat from the [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61824 OWASP Source Code Center at Sourceforge]. There are versions with and without Java, and installation only requires unzipping the download and running a start script. For convenience, a ready-to-deploy WAR file is also made available to drop right into your J2EE application server.

You can download the WebGoat source code from [http://code.google.com/p/webgoat/ Google code].

The WebGoat distributions are now available at [http://code.google.com/p/webgoat/downloads/list Google code downloads]. The Windows WebGoat release (unzip, click, and run) is only available at Sourceforge due to file size limits.

== Overview ==
[[Image:Webgoat-BasicAuth lesson.jpg|thumb|300px|right|The multi-stage Basic Authentication lesson]]
WebGoat is written in Java and therefore installs on any platform with a Java virtual machine. There are installation programs for Linux, OS X Tiger and Windows. Once deployed, the user can go through the lessons and track their progress with the scorecard. There are currently over 30 lessons, including those dealing with the following issues:
{|
|valign="top"|
* [[Cross Site Scripting]]
* Access Control
* [[Race condition within a thread|Thread Safety]]
* [[Unvalidated_Input|Hidden Form Field Manipulation]]
* Parameter Manipulation
* [[Session_Management#Weak_Session_Cryptographic_Algorithms|Weak Session Cookies]]
* Blind [[SQL injection|SQL Injection]]
|valign="top"|
* Numeric SQL Injection
* String SQL Injection
* [[Web Services]]
* [[Improper_Error_Handling|Fail Open Authentication]]
* Dangers of HTML Comments
* ... and many more!
|}

For more details, please see the [[WebGoat User and Install Guide Table of Contents | WebGoat User and Install Guide]].

== Newest Release ==

'''WebGoat 5.1 Release Candidate 1''' is available. This new release is platform independent. This release features:

* a new "show solution" feature
* Phishing lesson
* New database lessons - for Oracle and MS SQL Server databases only
* Multi-stage architecture which allows random access to lab stages

'''WebGoat 5.0'''

'''WebGoat 5.0''' has been released. Special thanks to the many people who have sent comments and suggestions and those who have put in the effort to contribute their time to this release.

The 5.0 release would not have been possible without the efforts of Sherif Koussa and [http://www.owasp.org/index.php/Owasp_Autumn_Of_Code_2006 OWASP Autumn of Code 2006].

Please send all comments to '''webgoat AT owasp.org''' regarding this release candidate. A final release is scheduled for the end of January

== Future Development ==

WebGoat 5.1 - Estimated release date: Fall 2007

WebGoat 5.1 - Is now available via svn at google code

If you would like to become a member of the WebGoat source code project hosted at [http://code.google.com/p/webgoat/ Google Code] contact Bruce Mayhew at '''webgoat AT owasp.org'''.

'''New Features in 5.1'''

* Thanks to the OWASP Spring of Code project, Erwin Geirhart has provided a complete solutions guide that is avaliable via a new "show solution" button

* New database lessons

* XSS phishing lesson is available via the source code project at Google. Using a standard search feature, your mission is to create a "login" form on the page, steal the user credentials, and post the credentials to the WebGoat Catcher servlet.

* Catcher servlet. Want to prove your attack works? You can now write lessons where the attack can send sensitive information to the Catcher servlet. The Catcher servlet will write the posted values into the originating lesson's properties file.

* Documentation. A draft version of how to solve the WebGoat Labs is available at [http://webgoat.googlecode.com/files/Solving%20the%20WebGoat%20Labs%20Draft%20V2.pdf WebGoat Google Code Downloads]

== Project Contributors ==

The WebGoat project is run by Bruce Mayhew. He can be contacted at '''webgoat AT owasp.org'''. WebGoat distributions are currently maintained on [[http://www.sourceforge.net SourceForge]]. The WebGoat framework makes it extremely easy to add additional lessons. We are actively seeking developers to add new lessons as new web technologies emerge. If you are interested in volunteering for the project, or have a comment, question, or suggestion, please join the WebGoat [[http://lists.owasp.org/mailman/listinfo/owasp-webgoat mailing list]].

== Project Sponsors ==

The WebGoat project is sponsored by
[http://www.aspectsecurity.com https://www.owasp.org/images/3/30/100px-Aspect_Security_Logo.jpg]

[[Category:OWASP Project]]
[[Category:OWASP Download]]
[[Category:OWASP Tool]]

__NOTOC__

OWASP WebScarab Differences (Classic vs NG)

2008-01-14T09:19:32Z

RoganDawes: Recategorise this project

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG does not yet have the Transcoder functionality.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy and Manual Request plugins.

Some features of the Proxy plugin remain to be ported:
* Ability to specify regexes for URL's (not) to be intercepted
* Ability to specify a regex for conversations that should not be stored
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is in progress.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

==Execution==

WebScarab NG is currently only executable via Java WebStart, which is likely to pose a problem for certain folk. Maven does have a fatjar plugin which should be able to construct a single jar with all its dependencies. This needs to be investigated.

[[Category:OWASP WebScarab Project]]
[[Category:OWASP WebScarab NG Project]]

OWASP WebScarab NG Project Technical Info

2008-01-14T09:18:47Z

RoganDawes: Recategorise this project

'''WebScarab (Next Generation) Technical Information'''

==Accessing the HSQL Database==

WebScarab-NG defaults to using the HSQLDB database libraries. If you are interested in digging into the DB manually, here's what you need to know.

===Getting the JAR===

Since WebScarab-NG is only available via Java Web Start at the moment, the HSQLDB libraries are unlikely to be anywhere convenient. So download the [[http://dawes.za.net/rogan/webscarab-ng/webstart/hsqldb-1.8.0.1.jar | jar]], and place it somewhere handy.

===Accessing the DB===

HSQLDB comes with a graphical client that allows you to explore the database, and execute arbitrary SQL.

You can invoke it by running:

$ java -cp hsqldb-1.8.0.1.jar org.hsqldb.util.DatabaseManager

It will prompt you to connect to the DB, by providing a URL. Simply copy and paste the same URL that you see in the WebScarab-NG dialog.

NOTE: Since it is run "in-process" in WebScarab-NG, it is not possible to access it concurrently from another application. You may be successful running HSQLDB in server mode, and specifying an appropriate URL to WS-NG when it starts, but keep in mind that (at the moment) WS-NG executes "SHUTDOWN" on the DB as it exits, in order to have a clean DB file, and no redo logs, etc. This could be changed if necessary.

===Important tables===

Once you have the DB open, it is just SQL ;-)

The key table is the "conversations" table.

conversations.createTable.hsqldb=\
CREATE CACHED TABLE conversations (\
session_id INT NOT NULL, \
id INTEGER GENERATED BY DEFAULT AS IDENTITY\
(START WITH 1) PRIMARY KEY,\
source_id INT NOT NULL,\
request_date TIMESTAMP NOT NULL,\
request_method_id INT NOT NULL,\
request_uri_id INT NOT NULL,\
request_version_id INT NOT NULL,\
request_content_id CHAR(32),\
response_version_id INT NOT NULL,\
response_status CHAR(3) NOT NULL,\
response_message_id INT NOT NULL,\
response_content_id CHAR(32)\
)

This keeps a record of every conversation that WS-NG knows about. The
columns should be quite self-explanatory.

This table works in conjunction with the headers and named_values tables
to record the request and response headers, as well as the blobs table
to record the request and response content. The blobs table is indexed
by the MD5 sum of the content.

So it is quite easy to reconstruct a conversation by finding the entry
in the conversations table, getting the headers from the
headers/named_values tables, and the content from the blobs table. And
obviously, the other fields are indexed into appropriate tables
(method_id -> methods, uri_id -> uris, etc)

Comments on my normalization are welcome - it's been almost 15 years
since my databases class at university!

===Database schema changes===

Databases created by versions of WebScarab-NG before 20070118 will be incompatible with versions after that date. Certain table columns were renamed to make it easier to accommodate other databases, by avoiding keywords, etc.

If you have an early DB, and would like to regain access to it, you need to run the following script using the DatabaseManager as described above:

ALTER TABLE conversations ALTER COLUMN session RENAME TO session_id;
ALTER TABLE conversations ALTER COLUMN source RENAME TO source_id;
ALTER TABLE conversations ALTER COLUMN date RENAME TO request_date;
ALTER TABLE conversations ALTER COLUMN request_method RENAME TO request_method_id;
ALTER TABLE conversations ALTER COLUMN request_uri RENAME TO request_uri_id;
ALTER TABLE conversations ALTER COLUMN request_version RENAME TO request_version_id;
ALTER TABLE conversations ALTER COLUMN request_content_key RENAME TO request_content_id;
ALTER TABLE conversations ALTER COLUMN response_version RENAME TO response_version_id;
ALTER TABLE conversations ALTER COLUMN response_message RENAME TO response_message_id;
ALTER TABLE conversations ALTER COLUMN response_content_key RENAME TO response_content_id;
ALTER TABLE blobs ALTER COLUMN key RENAME TO id;
ALTER TABLE blobs ALTER COLUMN size RENAME TO blob_size;
ALTER TABLE blobs ALTER COLUMN blob RENAME TO blob_content;
ALTER TABLE headers ALTER COLUMN conversation RENAME TO conversation_id;

which will rename the columns for you.

==Feedback==

If you have any comments or suggestions for WebScarab-NG, please feel free to send them to the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP WebScarab mailing list]

Your feedback is much appreciated, and will be carefully considered for future releases of WebScarab-NG.

==Project Contributors==

The WebScarab-NG project is run by Rogan Dawes of Aspect Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP WebScarab NG Project]]

OWASP WebScarab NG Project

2008-01-14T09:18:28Z

RoganDawes: Recategorise this project

'''Welcome to the WebScarab (Next Generation) Project'''

WebScarab-NG is a complete rewrite of the old WebScarab application, with a special focus on making the application more user-friendly. To this end, WebScarab-NG makes use of the [http://spring-rich-c.sourceforge.net/ Spring Rich Client Platform ] to provide the user interface features. By using the Spring Rich Client Platform, WebScarab-NG automatically gains things like default buttons, keyboard shortcuts, support for internationalisation, etc.

Another new feature is that session information is now written into a database, rather than into hundreds or thousands of individual files. This makes disk space utilisation and things like archiving of sessions a lot easier.

Ultimately, WebScarab-NG will have all the significant functionality that the old WebScarab had, although it will be reorganised quite significantly, in order to make the application more user friendly.

==New User Interface==

As mentioned above, the user interface has changed quite a lot from the old WebScarab. Apart from the new default Look&Feel (JGoodies), you will see that the conversation viewer has changed quite a lot. The old "Raw" view is still there, but the Parsed version has changed quite dramatically - for the better, I hope you'll agree!

The Parsed view now shows the request and response details in a tree form, rather than in individual text boxes. This makes the interface look a lot cleaner, and more importantly, is a lot more compact. It also makes it a lot easier to include features like automatically breaking out URL parameters, and multiple cookies into their own nodes, where it is a lot easier to view the individual parameters. We also show the request and the response next to each other, rather than one above the other, since most people seem to have more horizontal real-estate than vertical. The split between request and response can easily be adjusted by dragging, as can the split between the headers and the message content.

[[Image:WebScarab-NG-default.png]]

==Current status==

At this stage, WebScarab-NG primary feature is the intercepting proxy that allows the operator to observe and modify requests from a browser or other client passing through the proxy. A new feature is the Proxy Control Bar, which is implemented as a "stays on top" tool bar that floats above your browser or other thick client, and allows you to quickly enable or disable request intercepts. It also allows you to annotate or describe the requests as they pass through the proxy. If you type some text into the annotation field, that text will be linked to the next conversation that passes through the proxy, and can later be viewed as part of the conversation history. this can be very helpful to keep track of what you were doing in a multi-step procedure.

For example: Selecting a menu item, entering a value, submitting that value, etc. Often sites are built in such a way that they can result in dozens of conversations resulting from a single action. Annotating that conversation that initiated all the rest makes it very easy to identify them at a later stage.

[[Image:WebScarab-NG-proxy-control-bar.png]]

==Error feedback==

One of the neat features provided by the Spring Rich Client Platform is the ability to check that the inputs actually make sense, and to provide automated "as you type" feedback to the user.

For example, look at the "Intercept Request" window:

[[Image:WebScarab-NG-intercept-request-error.png]]

We can see that the user tried to change the method from "POST" to "PROST". WebScarab-NG has no idea how to execute a "PROST" method, and so provides an error message to inform the user. Additionally, the OK button is automatically disabled, until the error is corrected.

==Obtaining WebScarab-NG==

WebScarab-NG is distributed via Java WebStart, and can be obtained [http://dawes.za.net/rogan/webscarab-ng/webstart/WebScarab-ng.jnlp here].

A major benefit of using Java WebStart is that users will automatically receive new versions of WebScarab-Ng as they are made available, since WebStart checks to see if a new version is available each time it is run. Of course, if it is run with no access to the Internet, it will still run.

Note: there is an issue with signing the application and Java web start if you are using Java 1.6.
We are investigating the solution. In the meantime, you can still use WebScarab NG with an older
version of Java (without messing up your system).

"set PATH="c:\Program Files\Java\jdk1.5.0_06\bin" or whatever
"javaws http://dawes.za.net/rogan/webscarab-ng/webstart/WebScarab-ng.jnlp

Depending on demand, once WebScarab NG matures, it will also be made available for offline installation.

For information about what changes have been made, please see [http://dawes.za.net/gitweb.cgi?p=rogan/webscarab-ng/webscarab-ng.git;a=summary the GIT repository]

If you want to get a copy of the source, you can download a snapshot from the gitweb repository viewer. Alternatively, if you want to check out the repo using git, you can use the following command:

$ git clone http://dawes.za.net/rogan/webscarab-ng/webscarab-ng.git/

You can get any subsequent changes using:

$ git fetch origin

==Technical information==

Technical information for those interested in digging into it can be found [[ OWASP WebScarab NG Project Technical Info | here]]

==Feedback==

If you have any comments or suggestions for WebScarab-NG, please feel free to send them to the [http://lists.owasp.org/mailman/listinfo/owasp-webscarab OWASP WebScarab mailing list]

Your feedback is much appreciated, and will be carefully considered for future releases of WebScarab-NG.

==Project Contributors==

The WebScarab-NG project is run by Rogan Dawes of Aspect Security. He can be contacted at rogan AT dawes.za.net

[[Category:OWASP Download]]
[[Category:OWASP WebScarab NG Project]]

OWASP WebScarab NG Project

2008-01-11T16:03:36Z

RoganDawes: /* Obtaining WebScarab-NG */

Talk:Chaining WebScarab onto another proxy

2008-01-09T08:59:48Z

RoganDawes: Answer

== Questions ==

'''How do I specify the user name and password for an authenticated Proxy?'''

I am running behind a firewall/proxy that requires authentication. There is no UI for entering a user name and password required for the chained proxy.

I looked at the source code to see if it is a feature that is supported, but undocumented. It appears to not be an option, however WebScarab uses the jcifs library so it can do an authenticated NTLM proxy connection if it was coded.

[[User:Nchristiansen|Nchristiansen]] 17:46, 8 January 2008 (EST)

Take a look at the Tools -> Credentials dialog. There is an option to "Ask when required", which will tell WebScarab to respond to any authentication requests, rather than passing that through to the browser.

--[[User:RoganDawes|RoganDawes]] 03:59, 9 January 2008 (EST)
----

OWASP WebScarab Differences (Classic vs NG)

2008-01-08T17:15:43Z

RoganDawes: How to execute WS-NG

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG does not yet have the Transcoder functionality.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy and Manual Request plugins.

Some features of the Proxy plugin remain to be ported:
* Ability to specify regexes for URL's (not) to be intercepted
* Ability to specify a regex for conversations that should not be stored
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is in progress.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

==Execution==

WebScarab NG is currently only executable via Java WebStart, which is likely to pose a problem for certain folk. Maven does have a fatjar plugin which should be able to construct a single jar with all its dependencies. This needs to be investigated.

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP WebScarab Project]]

OWASP WebScarab Differences (Classic vs NG)

2008-01-08T08:09:46Z

RoganDawes: /* Framework functionality */

'''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation'''

The objective is to list the major features that one has over the other, with the intent to track the porting of desirable features from Classic to NG.

==Framework functionality==

NG has no concept of the shared cookie jar, which is used in Classic to allow plugins such as the Spider and Manual Request plugins to use the most current cookies for a particular URL. This could/should be replaced by an Identity module, which can provide the most current identifiers for a particular identity (cookies, Basic auth, etc).

NG does not yet have the Transcoder functionality.

==Plugins==

NG has significantly fewer plugins than Classic. The only plugins currently implemented in NG are the Proxy and Manual Request plugins.

Some features of the Proxy plugin remain to be ported:
* Ability to specify regexes for URL's (not) to be intercepted
* Ability to specify a regex for conversations that should not be stored
* BeanShell scripts for programmatic modification of requests/responses
* Miscellaneous proxy plugins - Reveal hidden fields, prevent caching of responses
* Ability to modify Internet Explorer proxy settings automatically on startup and exit

Some features of the Manual Request plugin remain to be ported:

* Ability to convert a request from a GET to a POST or multipart POST, and vice versa.

This leaves the following plugins to be implemented:

* Spider
* Extensions
* XSSCRLF
* SessionIDAnalysis
* Scripting
* Fragments
* Compare
* Search

Porting of the WebServices plugin to NG is in progress.

==Porting suggestions==

For people interested in contributing to this project by porting one of the above plugins, here are some suggestions:

* SessionID analysis
The current session id analysis plugin, while looking cool is actually very misleading. Anyone wanting to implement this feature for NG would be advised to take a look at Michal Zalewski's stompy to see how it can be done better.

* Search, Compare
These plugins are very clunky to use. It actually makes a lot more sense to make those features available as part of the primary interface, rather than relegating them to a backwater. Search should provide a simple interface where the operator can type some text and click Go, rather than having to write code.

* Spider
This plugin should also identify FORMs in the HTML responses, and identify those that have been submitted by matching them with the parameters of GET requests, or the bodies of POST's, using an intelligent matching algorithm. (Empty parameters in the form may be matched to anything in a GET/POST)

[[Category:OWASP Project]]
[[Category:OWASP Tool]]
[[Category:OWASP Download]]
[[Category:OWASP WebScarab Project]]

OWASP WebScarab Differences (Classic vs NG)

2008-01-07T17:21:39Z

RoganDawes: New page: '''This page is intended to document the differences between WebScarab Classic and WebScarab Next Generation''' The objective is to list the major features that one has over the other, wi...

WebScarab Getting Started

2007-08-29T11:57:56Z

RoganDawes: Add instructions for IE7, as well as explain how to configure a "Primary proxy"?

'''WebScarab''' has a large amount of functionality, and as such can be quite intimidating to the new user. But, for the simplest case, intercepting and modifying requests and responses between a browser and HTTP/S server, there is not a lot that needs to be learned.

Initially, I will assume that you have full unrestricted access to the Internet (that is, you are not behind a proxy). For the sake of simplicity, I will also assume that you are using Internet Explorer. If you need to use a proxy to get out of your corporate network, , see [[ Chaining_WebScarab_onto_another_proxy ]]

[[Image:WebScarab_startup.png]]

This is what WebScarab looks like at startup. There are a few major areas that might need explanation.

Firstly, the toolbar provides access to the various plugins, as well as the Summary window (main view), and messages (log) window.

The Summary window is split into two parts. On the top is a tree table which will show the layout of the sites that you have visited, and some attributes of the various URLs. Below that is a table showing all of the conversations that have been seen by WebScarab, normally sorted in reverse by ID, so that more recent conversations are at the top of the table. The sort order can be changed by clicking in the column headers if desired.

In order to start using WebScarab as a proxy, you need to configure your browser to use WebScarab as a proxy. This is configured in IE using the Tools menu. Select Tools -> Internet Options -> Connections -> LAN Settings to get the proxy configuration dialog.

[[Image:IE Proxy.PNG]]

WebScarab defaults to using port 8008 on localhost for its proxy. You need to configure IE to relay requests to WebScarab, rather than fetching them itself, as shown in the above image. Make sure that all checkboxes are unchecked, except for "Use a proxy server". Once you have configured IE to use the proxy, select Ok on all dialogs to get back to the browser. Browse to a non-SSL website, and then switch to WebScarab.

You should see something similar to the next image. If you don't, or you get an error while browsing, you should go back and check your proxy settings in Internet Explorer as described above. If the proxy settings are correct, one possibility is that there is already another program that is using port 8008, and preventing WebScarab from using it. If so, you should stop that other program. I will also show you how to tell WebScarab how to use a different port a bit later.

'''NOTE:''' If you are using WebScarab to test a site that is running the same computer as the browser (i.e. localhost or 127.0.0.1), and you are using IE7, you will need to add a dot "." after the hostname to force IE7 to use the proxy that you have configured. This is NOT a bug in WebScarab, but an unfortunate design decision (I assume) made by the developers of IE. Basically, it will ignore any proxy settings if it thinks that the server you are trying to reach is on the local machine. One way of tricking it is to add the dot, as in http://localhost./WebGoat/attack. This will force IE to use your configured proxy.

[[Image:WebScarab after browsing.png]]

Here you can see the tree of URL's, which represents the site layout, as well as the individual conversations that have passed through WebScarab. To see the details of a particular conversation, you can double-click on a row in the table, and a window showing the request and the details of the response will open. You can see the request and response in a variety of forms. The view shown here is the "Parsed" view, where the headers are broken out into a table, and the request or response content is presented according to its Content-Type header. You can also choose the "Raw" format, where the request or response is presented exactly as it would be seen on the wire.

[[Image:WebScarab conversation.png]]

You can step from one conversation (request/response) to the next in the conversation window using the "previous" and "next" buttons, as well as jumping directly to a particular conversation using the drop down combo box.

Now that you are familiar with the basic workings of WebScarab, and have made sure that your browser is correctly configured, the next step is to intercept some requests, and modify them before they are sent to the server.

You enable proxy intercepts via the Proxy plugin, accessible via the "Proxy" button on the toolbar. Then choose the "Manual Edit" tab. Once you click the "Intercept Requests" checkbox, you can choose which request methods you wish to intercept (most commonly GET or POST), and can even choose multiple methods using "Ctrl-click". Select "GET" for the moment.

[[Image:Webscarab configure intercept.png]]

Now go back to your browser, and click on a link. You should see something like the following window appear (it may only flash in the task bar initially, just select it. Future windows will pop-up properly).

[[Image:WebScarab intercept request.png]]

You can now edit any part of the request you choose. Note that the headers are shown already URL-decoded, and anything that you type in will be URL-encoded automatically. If you do not want this to happen, you should use the Raw mode. In some cases, using the Raw mode may be the easiest anyway, especially if you have something that you wish to paste in.

Once you are happy with your changes, click on the '''"Accept changes"''' button to allow the modified request to be sent to the server. If you decide that you wish to revert the changes that you have made so far, you can click on the '''"Cancel changes"''' button to allow the original request to be sent to the server. You can also click on the '''"Abort request"''' button if you don't want to send a request to the server at all. This will send an error back to the browser. Finally, if there are multiple intercept windows opened (e.g the browser is using several threads simultaneously), you can release all the requests using the '''"Cancel ALL intercepts"''' button.

WebScarab will continue to intercept all requests that match the method you specified until you uncheck the "Intercept requests" checkbox, either in the '''intercept conversation''' window, or in the '''"Manual Edit"''' tab of the '''Proxy''' plugin. But you may be wondering why WebScarab does not intercept requests for images, stylesheets, javascript, etc. If you go back to the '''"Manual Edit"''' tab, you will see a field labeled "Exclude paths matching:". This field contains a regular expression which is matched against the request URL. If there is a match, the request is never intercepted.

You can also configure WebScarab to intercept responses, in case you want to change the behaviour of some parts of the page. For example, you can disable JavaScript validation, change the list of possible items in a '''SELECT''' field, etc.

== Tips and tricks ==

If you are using IE and you would like WebScarab to automatically update your proxy settings for you, you need to complete the following steps. '''Note:''' This only works with the -installer version of WebScarab!

* Change to the Full-Featured interface (Tools -> Use Full-featured Interface), then go to the Proxy->Listeners tab.
* Select the only listener showing, and click "Stop".
* About 2/3 of the way down the screen are several input fields, corresponding to the columns in the listener table.
* Each box should be filled in with the value from the most recently stopped proxy.
* At this point, you can check the "Primary" checkbox, and then click "Start".

Your IE proxy settings will automatically be updated to point to WebScarab, and will be reset when you exit WebScarab. This setting will be saved, and used on subsequent runs of WebScarab.

[[Category:How To]]
[[Category:OWASP WebScarab Project]]