OWASP - User contributions [en]

Testing for Web Application Fingerprint (OWASP-IG-004)

2015-12-02T11:12:48Z

Eduardo Castellanos Najera: Removed desenmascara.me since it is no longer relevant.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Web server fingerprinting is a critical task for the Penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

There are several different vendors and versions of web servers on the market today. Knowing the type of web server that you are testing significantly helps in the testing process, and will also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely, however, different versions react the same to all HTTP commands. So, by sending several different commands, you increase the accuracy of your guess.

== Test Objectives ==

== How to Test ==

=== Black Box testing and example ===
The simplest and most basic form of identifying a Web server is to look at the Server field in the HTTP response header. For our experiments we use netcat.
Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html
</pre>

From the ''Server'' field, we understand that the server is likely Apache, version 1.3.3, running on Linux operating system.

Four examples of the HTTP response headers are shown below.

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>

From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>
However, this testing methodology is not so good. There are several techniques that allow a web site to obfuscate or to modify the server banner string.
For example we could obtain the following answer:
<pre>
403 HTTP/1.1 Forbidden
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
</pre>

In this case, the server field of that response is obfuscated: we cannot know what type of web server is running.

==== Protocol behaviour ====
More refined techniques take in consideration various characteristics of the several web servers available on the market. We will list some methodologies that allow us to deduce the type of web server in use.

'''HTTP header field ordering'''

The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. We consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>
We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise, and IIS.

'''Malformed requests test'''

Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
Consider the following HTTP responses.

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>
We notice that every server answers in a different way. The answer also differs in the version of the server. Similar observations can be done we create requests with a non-existent protocol. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

== Tools ==
* httprint - http://net-square.com/httprint.html
* httprecon - http://www.computec.ch/projekte/httprecon/
* Netcraft - http://www.netcraft.com
* Shodan - http://www.shodanhq.com
* Nmap - http://nmap.org

=== Automated Testing ===
Rather than rely on manual bannering and analysis of the web server headers, a tester can use automated tools to achieve the same purpose. The tests to carry out in order to accurately fingerprint a web server can be many. Luckily, there are tools that automate these tests. "''httprint''" is one of such tools. httprint has a signature dictionary that allows one to recognize the type and the version of the web server in use. 
An example of running httprint is shown below: 

[[Image:httprint.jpg |800px|]]

[http://www.nmap.org Nmap] version detection offers a lot of advanced features that can help in determining services that are running on a given host, it obtains all data by connecting to open ports and interrogating them by using probes that the specific services understand, the following example shows how Nmap connected to port 80 in order to fingerprint the service and its current version

<pre>
localhost$ nmap -sV example.com
Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-21 13:20 GST
Nmap scan report for example.com (127.0.0.1)
Host is up (0.028s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 6.0
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
</pre>

=== Online Testing ===
Online tools can be used if the tester wishes to test more stealthily and doesn't wish to directly connect to the target website. An example of online tool that often delivers a lot of information on target Web Server, are [http://www.netcraft.com Netcraft] and [http://www.shodanhq.com SHODAN]

With [http://www.netcraft.com Netcraft] we can retrieve information about operating system, web server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S. An example is shown below:
 

[[Image:netcraft2.png |800px|]]

SHODAN combines an HTTP port scanner with a search engine index of the HTTP responses, making it trivial to find specific web servers. Shodan collects data mostly on web servers at the moment (HTTP port 80), but there is also some data from FTP (21), SSH (22) Telnet (23), SNMP (161) and SIP (5060) services. An example is shown below:
 

[[File:Shodan.png |800px|]]

[[OWASP Unmaskme Project]] expect becomes another online tool to do fingerprinting in any website with an overall interpretation of all the [[Web-metadata]] extracted. The idea behind this project is that anyone in charge of a website could test the metadata their site is showing to the world and assess it from a security point of view.
While this project is being developed, you can test a [http://desenmascara.me/ Spanish Proof of Concept of this idea].

== Vulnerability References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://www.net-square.com/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html
* Nmap "Service and Application Version Detection" - http://nmap.org/book/vscan.html

== Remediation ==

Protect the presentation layer web server behind a hardened reverse proxy.

Obfuscate the presentation layer web server headers.
* Apache
* IIS

Fingerprint Web Server (OTG-INFO-002)

2015-12-02T11:11:26Z

Eduardo Castellanos Najera: Removed desenmascara.me since it is no longer relevant.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Web server fingerprinting is a critical task for the penetration tester. Knowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.

There are several different vendors and versions of web servers on the market today. Knowing the type of web server that is being tested significantly helps in the testing process and can also change the course of the test. This information can be derived by sending the web server specific commands and analyzing the output, as each version of web server software may respond differently to these commands. By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures. Please note that it usually takes several different commands to accurately identify the web server, as different versions may react similarly to the same command. Rarely do different versions react the same to all HTTP commands. So by sending several different commands, the tester can increase the accuracy of their guess.

== Test Objectives ==
Find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits to use during testing.

== How to Test ==

=== Black Box testing ===
The simplest and most basic form of identifying a web server is to look at the Server field in the HTTP response header. Netcat is used in this experiment.

Consider the following HTTP Request-Response:
<pre>
$ nc 202.41.76.251 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 16 Jun 2003 02:53:29 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux)
Last-Modified: Wed, 07 Oct 1998 11:18:14 GMT
ETag: "1813-49b-361b4df6"
Accept-Ranges: bytes
Content-Length: 1179
Connection: close
Content-Type: text/html
</pre>

From the ''Server'' field, one can understand that the server is likely Apache, version 1.3.3, running on Linux operating system.

Four examples of the HTTP response headers are shown below.

From an '''Apache 1.3.23''' server:
<pre>
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>

From a '''Microsoft IIS 5.0''' server:
<pre>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
ETag: b0aac0542e25c31: 89d
Content-Length: 7369
</pre>

From a '''Netscape Enterprise 4.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>

From a '''SunONE 6.1''' server:
<pre>
HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Accept-Ranges: bytes
Connection: close
</pre>

However, this testing methodology is limited in accuracy. There are several techniques that allow a web site to obfuscate or to modify the server banner string. For example one could obtain the following answer:
<pre>
403 HTTP/1.1 Forbidden
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Server: Unknown-Webserver/1.0
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
</pre>

In this case, the server field of that response is obfuscated. The tester cannot know what type of web server is running based on such information.

==== Protocol Behavior ====
More refined techniques take in consideration various characteristics of the several web servers available on the market. Below is a list of some methodologies that allow testers to deduce the type of web server in use.

'''HTTP header field ordering'''

The first method consists of observing the ordering of the several headers in the response. Every web server has an inner ordering of the header. Consider the following answers as an example:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Content-type: text/HTML
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Content-length: 57
Accept-ranges: bytes
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:23:37 GMT
Content-length: 0
Content-type: text/html
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Connection: close
</pre>

We can notice that the ordering of the ''Date'' field and the ''Server'' field differs between Apache, Netscape Enterprise, and IIS.

'''Malformed requests test'''

Another useful test to execute involves sending malformed requests or requests of nonexistent pages to the server.
Consider the following HTTP responses.

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad Request
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Server: Apache/1.3.23
Connection: close
Transfer: chunked
Content-Type: text/HTML; charset=iso-8859-1
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / HTTP/3.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: W/e0d362a4c335be1: ae1
Content-Length: 133
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / HTTP/3.0

HTTP/1.1 505 HTTP Version Not Supported
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Connection: close
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / HTTP/3.0

HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
Date: Tue, 16 Jan 2007 15:25:00 GMT
Content-length: 0
Content-type: text/html
Connection: close
</pre>

We notice that every server answers in a different way. The answer also differs in the version of the server. Similar observations can be done we create requests with a non-existent HTTP method/verb. Consider the following responses:

Response from '''Apache 1.3.23'''
<pre>
$ nc apache.example.com 80
GET / JUNK/1.0

HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Accept-Ranges: bytes
Content-Length: 196
Connection: close
Content-Type: text/HTML
</pre>
Response from '''IIS 5.0'''
<pre>
$ nc iis.example.com 80
GET / JUNK/1.0

HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
</pre>
Response from '''Netscape Enterprise 4.1'''
<pre>
$ nc netscape.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
</BODY></HTML>
</pre>
Response from a '''SunONE 6.1'''
<pre>
$ nc sunone.example.com 80
GET / JUNK/1.0

<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>
</pre>

== Tools ==
* httprint - http://net-square.com/httprint.html
* httprecon - http://www.computec.ch/projekte/httprecon/
* Netcraft - http://www.netcraft.com

=== Automated Testing ===
Rather than rely on manual banner grabbing and analysis of the web server headers, a tester can use automated tools to achieve the same results. There are many tests to carry out in order to accurately fingerprint a web server. Luckily, there are tools that automate these tests. "''httprint''" is one of such tools. httprint uses a signature dictionary that allows it to recognize the type and the version of the web server in use. 

An example of running httprint is shown below: 

[[Image:httprint.jpg]]

=== Online Testing ===
Online tools can be used if the tester wishes to test more stealthily and doesn't wish to directly connect to the target website. An example of an online tool that often delivers a lot of information about target Web Servers, is [http://www.netcraft.com Netcraft]. With this tool we can retrieve information about operating system, web server used, Server Uptime, Netblock Owner, history of change related to Web server and O.S. 
An example is shown below:
 

[[Image:netcraft2.png]]

[[OWASP Unmaskme Project]] is expected to become another online tool to do fingerprinting of any website with an overall interpretation of all the [[Web-metadata]] extracted. The idea behind this project is that anyone in charge of a website could test the metadata the site is showing to the world and assess it from a security point of view.

While this project is still being developed, you can test a [http://desenmascara.me/ Spanish Proof of Concept of this idea].

== References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://www.net-square.com/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html

== Remediation ==

Protect the presentation layer web server behind a hardened reverse proxy.

Obfuscate the presentation layer web server headers.
* Apache
* IIS

Fingerprint Web Application Framework (OTG-INFO-008)

2015-12-02T10:58:51Z

Eduardo Castellanos Najera: Undo previous revision. Referenced OWASP project has no releases and is inactive.

{{Template:OWASP Testing Guide v4}}
== Summary ==
Web framework[*] fingerprinting is an important subtask of the information gathering process. Knowing the type of framework can automatically give a great advantage if such a framework has already been tested by the penetration tester. It is not only the known vulnerabilities in unpatched versions but specific misconfigurations in the framework and known file structure that makes the fingerprinting process so important.

Several different vendors and versions of web frameworks are widely used. Information about it significantly helps in the testing process, and can also help in changing the course of the test. Such information can be derived by careful analysis of certain common locations. Most of the web frameworks have several markers in those locations which help an attacker to spot them. This is basically what all automatic tools do, they look for a marker from a predefined location and then compare it to the database of known signatures. For better accuracy several markers are usually used.

[*] Please note that this article makes no differentiation between Web Application Frameworks (WAF) and Content Management Systems (CMS). This has been done to make it convenient to fingerprint both of them in one chapter. Furthermore, both categories are referenced as web frameworks.

== Test Objectives ==
To define type of used web framework so as to have a better understanding of the security testing methodology.

== How to Test ==

=== Black Box testing ===
There are several most common locations to look in in order to define the current framework:
*HTTP headers
*Cookies
*HTML source code
*Specific files and folders

==== HTTP headers ====
The most basic form of identifying a web framework is to look at the ''X-Powered-By'' field in the HTTP response header. Many tools can be used to fingerprint a target. The simplest one is netcat utility.

Consider the following HTTP Request-Response:
<pre>
$ nc 127.0.0.1 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
X-Powered-By: Mono
</pre>

From the ''X-Powered-By'' field, we understand that the web application framework is likely to be Mono. However, although this approach is simple and quick, this methodology doesn't work in 100% of cases. It is possible to easily disable ''X-Powered-By'' header by a proper configuration. There are also several techniques that allow a web site to obfuscate HTTP headers (see an example in [[#Remediation]] chapter).

So in the same example the tester could either miss the ''X-Powered-By'' header or obtain an answer like the following:
<pre>
HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
X-Powered-By: Blood, sweat and tears
</pre>

Sometimes there are more HTTP-headers that point at a certain web framework. In the following example, according to the information from HTTP-request, one can see that ''X-Powered-By'' header contains PHP version. However, the ''X-Generator'' header points out the used framework is actually Swiftlet, which helps a penetration tester to expand his attack vectors. When performing fingerprinting, always carefully inspect every HTTP-header for such leaks.
<pre>
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT
Content-Type: text/html
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.16-1~dotdeb.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Generator: Swiftlet
</pre>

==== Cookies ====
Another similar and somehow more reliable way to determine the current web framework are framework-specific cookies.

Consider the following HTTP-request:

[[Image:Cakephp_cookie.png]]

The cookie ''CAKEPHP'' has automatically been set, which gives information about the framework being used. List of common cookies names is presented in chapter [[#Cookies_2]]. Limitations are the same - it is possible to change the name of the cookie. For example, for the selected ''CakePHP'' framework this could be done by the following configuration (excerpt from core.php):

<pre>
/**
* The name of CakePHP's session cookie.
*
* Note the guidelines for Session names states: "The session name references
* the session id in cookies and URLs. It should contain only alphanumeric
* characters."
* @link http://php.net/session_name
*/
Configure::write('Session.cookie', 'CAKEPHP');
</pre>

However, these changes are less likely to be made than changes to the ''X-Powered-By'' header, so this approach can be considered as more reliable.

==== HTML source code ====
This technique is based on finding certain patterns in the HTML page source code. Often one can find a lot of information which helps a tester to recognize a specific web framework. One of the common markers are HTML comments that directly lead to framework disclosure. More often certain framework-specific paths can be found, i.e. links to framework-specific css and/or js folders. Finally, specific script variables might also point to a certain framework.

From the screenshot below one can easily learn the used framework and its version by the mentioned markers. The comment, specific paths and script variables can all help an attacker to quickly determine an instance of ZK framework.

[[Image:Zk_html_source.png]]

More frequently such information is placed between <head></head> tags, in <meta> tags or at the end of the page. Nevertheless, it is recommended to check the whole document since it can be useful for other purposes such as inspection of other useful comments and hidden fields. Sometimes, web developers do not care much about hiding information about the framework used. It is still possible to stumble upon something like this at the bottom of the page:

[[Image:banshee_bottom_page.png]]

== Common frameworks ==
=== Cookies ===

{| class="wikitable"
|-
! Framework !! Cookie name
|-
| Zope || zope3
|-
| CakePHP || cakephp
|-
| Kohana || kohanasession
|-
| Laravel || laravel_session
|}

=== HTML source code ===
==== General markers ====
{| class="wikitable"
|-
| %framework_name%
|-
| powered by
|-
| built upon
|-
| running
|}

==== Specific markers ====
{| class="wikitable"
|-
! Framework !! Keyword
|-
| Adobe ColdFusion || 
|-
| Indexhibit || ndxz-studio
|}

=== Specific files and folders ===
Specific files and folders are different for each specific framework. It is recommended to install the corresponding framework during penetration tests in order to have better understanding of what infrastructure is presented and what files might be left on the server. However, several good file lists already exist and one good example is FuzzDB wordlists of predictable files/folders (http://code.google.com/p/fuzzdb/).

== Tools ==
A list of general and well-known tools is presented below. There are also a lot of other utilities, as well as framework-based fingerprinting tools.

=== WhatWeb ===
Website: http://www.morningstarsecurity.com/research/whatweb 
Currently one of the best fingerprinting tools on the market. Included in a default [[Kali Linux]] build.
Language: Ruby
Matches for fingerprinting are made with:
* Text strings (case sensitive)
* Regular expressions
* Google Hack Database queries (limited set of keywords)
* MD5 hashes
* URL recognition
* HTML tag patterns
* Custom ruby code for passive and aggressive operations

Sample output is presented on a screenshot below:

[[Image:whatweb-sample.png]]

=== BlindElephant ===
Website: https://community.qualys.com/community/blindelephant 
This great tool works on the principle of static file checksum based version difference thus providing a very high quality of fingerprinting.
Language: Python

Sample output of a successful fingerprint:
<pre>
pentester$ python BlindElephant.py http://my_target drupal
Loaded /Library/Python/2.7/site-packages/blindelephant/dbs/drupal.pkl with 145 versions, 478 differentiating paths, and 434 version groups.
Starting BlindElephant fingerprint for version of drupal at http://my_target

Hit http://my_target/CHANGELOG.txt
File produced no match. Error: Retrieved file doesn't match known fingerprint. 527b085a3717bd691d47713dff74acf4

Hit http://my_target/INSTALL.txt
File produced no match. Error: Retrieved file doesn't match known fingerprint. 14dfc133e4101be6f0ef5c64566da4a4

Hit http://my_target/misc/drupal.js
Possible versions based on result: 7.12, 7.13, 7.14

Hit http://my_target/MAINTAINERS.txt
File produced no match. Error: Retrieved file doesn't match known fingerprint. 36b740941a19912f3fdbfcca7caa08ca

Hit http://my_target/themes/garland/style.css
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 7.10, 7.11, 7.12, 7.13, 7.14

...

Fingerprinting resulted in:
7.14

Best Guess: 7.14
</pre>

=== Wappalyzer ===
Website: http://wappalyzer.com 
Wapplyzer is a Firefox Chrome plug-in. It works only on regular expression matching and doesn't need anything other than the page to be loaded on browser. It works completely at the browser level and gives results in the form of icons. Although sometimes it has false positives, this is very handy to have notion of what technologies were used to construct a target website immediately after browsing a page.

Sample output of a plug-in is presented on a screenshot below.

[[Image:Owasp-wappalyzer.png]]

== References ==
'''Whitepapers''' 
* Saumil Shah: "An Introduction to HTTP fingerprinting" - http://www.net-square.com/httprint_paper.html
* Anant Shrivastava : "Web Application Finger Printing" - http://anantshri.info/articles/web_app_finger_printing.html

== Remediation ==
The general advice is to use several of the tools described above and check logs to better understand what exactly helps an attacker to disclose the web framework. By performing multiple scans after changes have been made to hide framework tracks, it's possible to achieve a better level of security and to make sure of the framework can not be detected by automatic scans. Below are some specific recommendations by framework marker location and some additional interesting approaches.

==== HTTP headers ====
Check the configuration and disable or obfuscate all HTTP-headers that disclose information the technologies used. Here is an interesting article about HTTP-headers obfuscation using Netscaler:
http://grahamhosking.blogspot.ru/2013/07/obfuscating-http-header-using-netscaler.html

==== Cookies ====
It is recommended to change cookie names by making changes in the corresponding configuration files.

==== HTML source code ====
Manually check the contents of the HTML code and remove everything that explicitly points to the framework.

General guidelines:
*Make sure there are no visual markers disclosing the framework
*Remove any unnecessary comments (copyrights, bug information, specific framework comments)
*Remove META and generator tags
*Use the companies own css or js files and do not store those in a framework-specific folders
*Do not use default scripts on the page or obfuscate them if they must be used.

==== Specific files and folders ====
General guidelines:
*Remove any unnecessary or unused files on the server. This implies text files disclosing information about versions and installation too.
*Restrict access to other files in order to achieve 404-response when accessing them from outside. This can be done, for example, by modifying htaccess file and adding RewriteCond or RewriteRule there. An example of such restriction for two common WordPress folders is presented below.
<pre>
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]
RewriteCond %{REQUEST_URI} /wp-admin/$
RewriteRule $ /http://your_website [R=404,L]
</pre>

However, these are not the only ways to restrict access. In order to automate this process, certain framework-specific plugins exist. One example for WordPress is StealthLogin (http://wordpress.org/plugins/stealth-login-page).

==== Additional approaches ====
General guidelines:
*Checksum management
*:The purpose of this approach is to beat checksum-based scanners and not let them disclose files by their hashes. Generally, there are two approaches in checksum management:
*:*Change the location of where those files are placed (i.e. move them to another folder, or rename the existing folder)
*:*Modify the contents - even slight modification results in a completely different hash sum, so adding a single byte in the end of the file should not be a big problem.
*Controlled chaos
*:A funny and effective method that involves adding bogus files and folders from other frameworks in order to fool scanners and confuse an attacker. But be careful not to overwrite existing files and folders and to break the current framework!

OWASP Day Guatemala 2011

2011-10-13T02:35:12Z

Eduardo Castellanos Najera:

El Intecap junto con OWASP Guatemala invitan a participar de la Primer Jornada de Seguridad en aplicaciones WEB “OWASP Day Guatemala”, que se realizará el próximo viernes 19 de agosto en el auditorio del Intecap ubicado en el Centro TICS Calle del Estadio Mateo Flores 8-79 Zona 5.

==== Resumen ====

'''Objetivos de la jornada:'''

El paradigma de desarrollo de los sistemas de información esta en constante cambio. La aparición de las tecnologías Web 2.0 permitió la amplia implantación y uso de aplicaciones basadas en web debido a su fácil escalabilidad y flexibilidad.
Como resultado de este cambio de paradigma, los requisitos de seguridad también han cambiado. Estos sistemas de información basados en web tienen requisitos de seguridad diferentes en comparación con los sistemas tradicionales. Asimismo, se han evidenciado importantes cuestiones de seguridad y protección de la privacidad que deben ser resueltas.
Esta jornada pretende reunir a expertos de seguridad de aplicaciones investigadores, educadores, profesionales de la industria, la academia y comunidades internacionales como OWASP, a fin de discutir dichos problemas y abrir nuevas soluciones en seguridad de aplicaciones.

'''A quien esta dirigido:'''

La charla está especialmente dirigida a Desarrolladores, Analistas de Software, Analistas de Seguridad, Gerentes de Proyectos IT, Responsables de la seguridad IT.

=== Programa del Evento ===

 
<center>
<table width="80%">
<tr>
<td width=4%>14:30h</td><td bgcolor="#BCA57A" width=*>Registro de Asistentes</td>
</tr>
<tr>
<td valign=top>15.00h</td><td bgcolor="#eeeeee"> Presentación OWASP Chapter Guatemala [http://tinyurl.com/3hmtojy Ver la Presentación] Camilo Fernandez </td>
</tr>
<tr>
<td valign=top>15.30h</td><td bgcolor="#b9c2dc">Las diez vulnerabilidades Web mas relevantes [http://www.slideshare.net/tabai/owasp-top-10 Ver la Presentación] Eduardo Castellanos </td>
</tr>
<tr>
<td valign=top>16.00h</td><td bgcolor="#eeeeee">MySQL: SQL injection utilizando Bit Shifting [http://bit.ly/p2lZB3 Ver la Presentación] Luis Cordon </td>
</tr>
<tr>
<td valign=top>16.30h</td><td bgcolor="#b9c2dc">PHP: Eliminando SQL injection utilizando data objects [http://slidesha.re/nxsNBC Ver la Presentación] Stuardo Rodriguez </td>
</tr>
<tr>
<td valign=top>17.00h</td><td bgcolor="#eeeeee">Intervalo - Coffee Break </td>
</tr>
<tr>
<td valign=top>17.30h</td><td bgcolor="#b9c2dc">.NET: Sanitizar input automáticamente [http://tinyurl.com/3ap5g3l Ver la Presentación] Mario Guzman [https://github.com/MarioFGC/Owasp.SQL Codigo SQL] [https://github.com/MarioFGC/Owasp.Passwords Codigo Passwords]</td>
</tr>
<tr>
<td valign=top>18.00h</td><td bgcolor="#eeeeee">JAVA: Java security vrs. frameworks de seguridad [http://www.slideshare.net/tuxtor/java-security-vs-frameworks Ver la Presentación] Victor Orozco </td>
</tr>
<tr>
<td valign=top>18.30h</td><td bgcolor="#b9c2dc">Móviles: Modelo de seguridad de Android [http://bit.ly/owaspAndroid Ver la Presentación] Adrian Catalan </td>
</tr>
<tr>
<td valign=top>19.00h</td><td bgcolor="#eeeeee">Mitigando amenazas desde la fase de diseño [http://tinyurl.com/3jgh78d Ver la Presentación] Camilo Fernandez </td>
</tr>
<tr>
<td valign=top>19.30h</td><td bgcolor="#BCA57A">Cierre del Evento y Rifas</td>
</tr>
<tr>
</tr>
</table>
</center>
 

==== Lugar y Fecha ====
 
'''Fecha''': Viernes 19 de Agosto de 15:00 a 19:00 hs
 
'''Lugar''': Auditorio del Intecap
 
'''Parqueo''': Q 10.00 por todo el evento en el parqueo del Intecap
 

==== Registro ====

 
La Conferencia es libre y abierta al publico de forma gratuita bajo previo registro.
Para garantízar un evento organizado, los que no esten registrados no se les permitirá el acceso.
 
IMPORTANTE: Hay 130 Vacantes, luego de su inscripción debe esperar la confirmación de la organización.
'''Parqueo''': <h2>Q 10.00 por todo el evento en el parqueo del Intecap.</h2>

<center>
Para inscribirse:

'''Registro Cerrado''' </center> 

==== Afiche ====
<center>[[File:OWASP_Guatemala.jpg]]</center>

__NOTOC__
<headertabs/>
[[Category:Latin America]]

Guatemala

2011-10-13T02:34:40Z

Eduardo Castellanos Najera:

{{Chapter Template|chaptername=OWASP-Guatemala|extra=The chapter leader is [mailto:cfernandez@develsecurity.com Camilo Fernandez] (CISM, CISA, CISSP, MCSE:Security, CHFI, CEH, CEPT, ISO27001 LEAD AUDITOR, Security+)|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-Guatemala|emailarchives=http://lists.owasp.org/pipermail/owasp-Guatemala}}

== Patrocinios ==

Hay muchas formas de colaborar y contribuir con el capitulo OWASP Guatemala. 

*Participando en cualquiera de los proyectos actualmente activos (documentación y herramientas).
*Proponiendo nuevos proyectos.
*Participando y aportando ideas en nuestra lista de correo.
*Asistiendo a las conferencias y reuniones.
*Promoviendo y dando soporte al proyecto OWASP en general.
*Coffee Breaks y rifas en nuestros eventos.

 

== Noticias del Capitulo ==

'''2010''': Este año, fuimos a nuestro país hermano de República Dominicana, a impulsar el proyecto OWASP. En este evento dimos las charlas que anteriormente habíamos brindando en nuestro Local Chapter, si desean leer una reseña de nuestras actividades por haya, les dejo el link de la noticia de una de las universidades donde brindamos la charla: [http://www.pucmm.edu.do/STI/campus/Facultades/ingenierias/departamentos/sistemas/Actividades/Paginas/CharlasobreSeguridadInformaticaAmenazas.aspx Ver Noticia] 

'''2009''': El año pasado tuvimos nuestro primer evento OWASP, en Guatemala. Tuvimos el privilegio de brindar dos charlas una en la universidad Galileo y la otra en la universidad del valle en Guatemala. A continuación les dejo una breve descripción de las charlas que se llevaron a cabo. 

*'''Introducción a la Seguridad Informática''': 

El objetivo de esta charla fue enseñar el campo de la seguridad informática en el mundo actual, esta rama de la informática es bastante reciente, si no totalmente en países latinoamericanos. La meta fue enseñar al alumno diferentes estadísticas adquiridas de los reportes anuales de empresas dentro del “Top 500”, en la rama de seguridad informática, dando a conocer las amenazas, inversiones, productos y tendencias dentro de esta especialidad, adicionalmente se explico que es la seguridad informática y su diferencia con la seguridad de la información, así como las diferentes especializaciones que uno puede aplicar dentro de este campo e instruir que esta es una especialidad adicional la cual los alumnos pueden adoptar luego de estar egresados como por ejemplo las especialidades conocidas de desarrollo de software, infraestructura, redes, etc. [http://www.owasp.org/images/8/89/Introduccion_a_Seguridad_Informatica.pdf Descarga la Presentación] 

*'''Introducción a la OWASP''': 

En esta charla se explico que es la organización OWASP (Open Web Application Security Project), así como los proyectos más famosos que han surgido de la misma, Entrando un poco en profundidad en el “Top 10 Security Risks” definidos por profesionales de seguridad de varias industrias alrededor del mundo, adicionalmente entramos a ver la “Testing Guide 3.0”, metodología para la generación de auditorías de seguridad para aplicaciones en línea, la cual se ha vuelto un pilar en metodologías de pruebas de intrusión, también vimos algunos otros proyectos que se están desarrollando internamente así como algunas herramientas que han surgido. [http://www.owasp.org/images/2/21/Introduccion_a_la_OWASP.pdf Descarga la Presentación] Adicionalmente dimos una charla técnica sobre un tema relacionado en seguridad. Si deseas ver los vídeos de las charlas o los comentarios de los alumnos que participaron en la actividad, puedes dirigirte al siguiente link: [http://chitiore.com/2009/09/01/conferencia-de-seguridad-informatica-por-camilo-fernandez-en-la-uvg/ Ver Noticia] 

 

== Reuniones ==

Se proponen reuniones trimestrales y grupos de estudio a formarse relacionados en temas de Seguridad Informatica. Se nombran alguno de ellos:
<ul>
<li> Análisis de las nuevas tecnologías de la información y las comunicaciones.</li>
<li>Análisis de productos (Software & Appliances).</li>
<li>Investigación de fallas y vulnerabilidades.</li>
<li>Desarrollo de programas y técnicas de exploit relacionadas.</li>
<li>Documentación de soluciones de seguridad.</li>
<li>Desarrollo de herramientas de seguridad.</li>
<li>Demostraciones. Debates y desarrollo investigativo.</li>
</ul>
 

== Beneficios para miembros ==

 
<center>
<table width="80%">
<tr>
<td bgcolor="#BCA57A" width=*></td>
</tr>
<tr>
<td bgcolor="#eeeeee">[[File:Logo_ds.jpg]] [http://www.develsecurity.com DevelSecurity] 10% de descuento en el curso de DEEP Hacking: [http://develsecurity.com/capacitacion.html DEEP Hacking] (Aclaracion: No es una actividad oficial de OWASP Fundation) </td>
</tr>
<tr>
<td bgcolor="#BCA57A"></td>
</tr>
<tr>
</tr>
</table>
</center>
 

== Próximos Eventos ==
 
* '''OWASP University Tour'''
<ul>
Proximamente estaremos realizando un visita por las universidades tecnologicas de Guatemala, llevando el desarrollo seguro a estudiantes y participantes de forma gratuita. 
</ul>

 
* '''[[OWASP Day Guatemala 2011]]'''
<ul>
El Intecap junto con OWASP Guatemala invitan a participar de la Primer Jornada de Seguridad en aplicaciones WEB “OWASP Day Guatemala”, que se realizará el próximo viernes 19 de agosto en el auditorio del Intecap ubicado en el Centro TICS Calle del Estadio Mateo Flores 8-79 Zona 5. 
</ul>

[[Category:Latin America]]

OWASP Day Guatemala 2011

2011-10-13T02:33:44Z

Eduardo Castellanos Najera:

==== Resumen ====

'''Objetivos de la jornada:'''

El paradigma de desarrollo de los sistemas de información esta en constante cambio. La aparición de las tecnologías Web 2.0 permitió la amplia implantación y uso de aplicaciones basadas en web debido a su fácil escalabilidad y flexibilidad.
Como resultado de este cambio de paradigma, los requisitos de seguridad también han cambiado. Estos sistemas de información basados en web tienen requisitos de seguridad diferentes en comparación con los sistemas tradicionales. Asimismo, se han evidenciado importantes cuestiones de seguridad y protección de la privacidad que deben ser resueltas.
Esta jornada pretende reunir a expertos de seguridad de aplicaciones investigadores, educadores, profesionales de la industria, la academia y comunidades internacionales como OWASP, a fin de discutir dichos problemas y abrir nuevas soluciones en seguridad de aplicaciones.

'''A quien esta dirigido:'''

La charla está especialmente dirigida a Desarrolladores, Analistas de Software, Analistas de Seguridad, Gerentes de Proyectos IT, Responsables de la seguridad IT.

=== Programa del Evento ===

 
<center>
<table width="80%">
<tr>
<td width=4%>14:30h</td><td bgcolor="#BCA57A" width=*>Registro de Asistentes</td>
</tr>
<tr>
<td valign=top>15.00h</td><td bgcolor="#eeeeee"> Presentación OWASP Chapter Guatemala [http://tinyurl.com/3hmtojy Ver la Presentación] Camilo Fernandez </td>
</tr>
<tr>
<td valign=top>15.30h</td><td bgcolor="#b9c2dc">Las diez vulnerabilidades Web mas relevantes [http://www.slideshare.net/tabai/owasp-top-10 Ver la Presentación] Eduardo Castellanos </td>
</tr>
<tr>
<td valign=top>16.00h</td><td bgcolor="#eeeeee">MySQL: SQL injection utilizando Bit Shifting [http://bit.ly/p2lZB3 Ver la Presentación] Luis Cordon </td>
</tr>
<tr>
<td valign=top>16.30h</td><td bgcolor="#b9c2dc">PHP: Eliminando SQL injection utilizando data objects [http://slidesha.re/nxsNBC Ver la Presentación] Stuardo Rodriguez </td>
</tr>
<tr>
<td valign=top>17.00h</td><td bgcolor="#eeeeee">Intervalo - Coffee Break </td>
</tr>
<tr>
<td valign=top>17.30h</td><td bgcolor="#b9c2dc">.NET: Sanitizar input automáticamente [http://tinyurl.com/3ap5g3l Ver la Presentación] Mario Guzman [https://github.com/MarioFGC/Owasp.SQL Codigo SQL] [https://github.com/MarioFGC/Owasp.Passwords Codigo Passwords]</td>
</tr>
<tr>
<td valign=top>18.00h</td><td bgcolor="#eeeeee">JAVA: Java security vrs. frameworks de seguridad [http://www.slideshare.net/tuxtor/java-security-vs-frameworks Ver la Presentación] Victor Orozco </td>
</tr>
<tr>
<td valign=top>18.30h</td><td bgcolor="#b9c2dc">Móviles: Modelo de seguridad de Android [http://bit.ly/owaspAndroid Ver la Presentación] Adrian Catalan </td>
</tr>
<tr>
<td valign=top>19.00h</td><td bgcolor="#eeeeee">Mitigando amenazas desde la fase de diseño [http://tinyurl.com/3jgh78d Ver la Presentación] Camilo Fernandez </td>
</tr>
<tr>
<td valign=top>19.30h</td><td bgcolor="#BCA57A">Cierre del Evento y Rifas</td>
</tr>
<tr>
</tr>
</table>
</center>
 

==== Lugar y Fecha ====
 
'''Fecha''': Viernes 19 de Agosto de 15:00 a 19:00 hs
 
'''Lugar''': Auditorio del Intecap
 
'''Parqueo''': Q 10.00 por todo el evento en el parqueo del Intecap
 

==== Registro ====

 
La Conferencia es libre y abierta al publico de forma gratuita bajo previo registro.
Para garantízar un evento organizado, los que no esten registrados no se les permitirá el acceso.
 
IMPORTANTE: Hay 130 Vacantes, luego de su inscripción debe esperar la confirmación de la organización.
'''Parqueo''': <h2>Q 10.00 por todo el evento en el parqueo del Intecap.</h2>

<center>
Para inscribirse:

'''Registro Cerrado''' </center> 

==== Afiche ====
<center>[[File:OWASP_Guatemala.jpg]]</center>

__NOTOC__
<headertabs/>
[[Category:Latin America]]

OWASP Day Guatemala 2011

2011-10-13T02:21:48Z

Eduardo Castellanos Najera: Created page with "==== Bienvenidos ==== El paradigma de desarrollo de los sistemas de información esta en constante cambio. La aparición de las tecnologías Web 2.0 permitió la amplia implantac..."

==== Bienvenidos ====
El paradigma de desarrollo de los sistemas de información esta en constante cambio. La aparición de las tecnologías Web 2.0 permitió la amplia implantación y uso de aplicaciones basadas en web debido a su fácil escalabilidad y flexibilidad.
Como resultado de este cambio de paradigma, los requisitos de seguridad también han cambiado. Estos sistemas de información basados en web tienen requisitos de seguridad diferentes en comparación con los sistemas tradicionales. Asimismo, se han evidenciado importantes cuestiones de seguridad y protección de la privacidad que deben ser resueltas.
Esta jornada pretende reunir a expertos de seguridad de aplicaciones investigadores, educadores, profesionales de la industria, la academia y comunidades internacionales como OWASP, a fin de discutir dichos problemas y abrir nuevas soluciones en seguridad de aplicaciones.

User talk:Eduardo Castellanos Najera

2011-10-13T02:09:44Z

Eduardo Castellanos Najera: Replaced content with "Security Analyst"

Security Analyst