<?xml version="1.0" encoding="utf-8" ?>
<alerts xmlns="http://tempuri.org/XMLSchemaOptions.xsd">
<!--

Paros and its related data files.

Paros is an HTTP/HTTPS proxy for assessing web application security.
Copyright (C) 2003-2004 www.proofsecure.com

This program is free software; you can redistribute it and/or
modify it under the terms of the Clarified Artistic License
as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
Clarified Artistic License for more details.

You should have received a copy of the Clarified Artistic License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-->

<!-- 

Only once entity encode is needed in this file.  Eg '<' should be encoded as &lt; but no need to be &amp;lt;
1	-	9999 for default file checks
10000	-	19999 for other harmless application checks
20000	-	29999 for checks which submit arbitrary parameters or potentially harmful check (eg sql injection where some server may hang)
30000	-	39999 for likely harmful check such as buffer overflow
90000   - 	above for custom check only
-->

<!--

This list the alerts
1		Microsoft IIS default file
2		ColdFusion default file
3		Macromedia JRun default file
4		Tomcat default file
5		BEA WebLogic default file
6		IBM WebSphere default file
10000	HTTP methods
10001	Directory browsing
10002	Obsolete files
10003	Secure page cache
10004	Password autocomplete
10005	Private IP disclosure
10006	Platform disclosure
10007	CRLF Injection
10008	Cipher suites list
10009	Cipher suite without encryption
10010	Server header info
10011	Set cookie header info
10012	Session ID in GET
10013	Referer expose session ID
10014	Cipher suite with weak strength
20000	Cross site script
20001	SQL injection
20002	Paramter tampering
20003	Perl Injection
20004	SSI Injection
30000	Exceeding long input
30001	Format string buffer overflow

To be developed:
.	Check session cookie for secured
.	check cipher suite
.	check SSI
.	handle cookie check in XSS and SQL injection
=======================================================

-->

<!-- below is the detail of the alert for reporting -->

**************************
1 - 9999 checks below
**************************
-->

<alertitem>
<id>1</id>
<alert>Microsoft IIS default files</alert>
<desc>Microsoft IIS 4.0, 5.0 or 6.0 default files are found.</desc>
<solution>Remove default file, virtual directory etc.</solution>
<reference></reference>
</alertitem>

<alertitem>
<id>2</id>
<alert>ColdFusion default files</alert>
<desc>ColdFusion MX default files are found.</desc>
<solution>Remove default files.</solution>
<reference></reference>
</alertitem>

<alertitem>
<id>2</id>
<alert>ColdFusion default files</alert>
<desc>ColdFusion MX default files are found.</desc>
<solution>Remove default files.</solution>
<reference></reference>
</alertitem>

<alertitem>
<id>3</id>
<alert>Macromedia JRun default files</alert>
<desc>JRun 4.0 default files are found.</desc>
<solution>Remove default files.</solution>
<reference></reference>
</alertitem>

<alertitem>
<id>4</id>
<alert>Tomcat source file disclosure</alert>
<desc>Tomcat source file disclosed.</desc>
<solution>Upgrade to newer version.</solution>
<reference></reference>
</alertitem>

<alertitem>
<id>5</id>
<alert>BEA WebLogic example files</alert>
<desc>BEA WebLogic server 8.1 example files are found.</desc>
<solution>Remove example files.</solution>
<reference></reference>
</alertitem>

<alertitem>
<id>6</id>
<alert>IBM WebSphere default files</alert>
<desc>IBM WebSphere 4.0/5.0 example files are found.</desc>
<solution>Remove example files.</solution>
<reference></reference>
</alertitem>
<!--
**************************
10000 - 19999 checks below
**************************
-->
<alertitem>
<id>10000</id>
<alert>HTTP methods</alert>
<desc>HTTP method such as PUT, DELETE, WebDAV etc appeared to exist as indicated by the OPTIONS method.  However, this may be a false-positive as they can be forbidden by other means</desc>
<solution>Disable PUT/DELETE/WebDAV support.
For IIS, disable WebDAV if not required as in reference.  Unneccessary method can also be filtered using UrlScan.</solution>
<reference>http://support.microsoft.com/default.aspx?kbid=241520</reference>
</alertitem>

<alertitem>
<id>10001</id>
<alert>Directory browsing</alert>
<desc>It is possible to view the directory listing.  Directory listing may reveal hidden scripts, include files , backup source files etc which be accessed to read sensitive information.</desc>
<solution>Disable directory browsing.  If this is required, make sure the file listed cannot make harm.</solution>
<reference>For IIS, turn off directory browsing.
For Apache, use the &quot;Options -Indexes&quot; directive to disable indexes in directory or via .htaccess:
. http://httpd.apache.org/docs/mod/core.html#options
. http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html
. or create a default index.html for each directory.
</reference>
</alertitem>

<alertitem>
<id>10002</id>
<alert>Obsolete file</alert>
<desc>Miscellenous include files, backup, unused or obsolete files exist as indicated.  If these files contain program source, information such as server logic or ODBC/JDBC user ID and passwords may be revealed since these file extension may not be processed by the web server.</desc>
<solution>Remove backup, unused or obsolete files.  For include files, carefully choose the suffix to prevent information disclosure.</solution>
</alertitem>

<alertitem>
<id>10003</id>
<alert>Secure page cache</alert>
<desc>Secure page can be cached in browser.  Cache control is not set in HTTP header nor HTML header.  Sensitive content can be recovered from browser storage.</desc>
<solution>The best way is to set HTTP header with:
'Pragma: No-cache' and 'Cache-control: No-cache'.
Alternatively, this can be set in the HTML header by:
&lt;META HTTP-EQUIV=&quot;Pragma&quot; CONTENT=&quot;no-cache&quot;&gt;
&lt;META HTTP-EQUIV=&quot;Cache-Control&quot; CONTENT=&quot;no-cache&quot;&gt;
but some browser may have problem using this method.</solution>
<reference>. How to prevent caching in Internet Explorer - http://support.microsoft.com/default.aspx?kbid=234067
. Pragma: No-cache Tag May Not Prevent Page from Being Cached - http://support.microsoft.com/default.aspx?kbid=222064
</reference>
</alertitem>

<alertitem>
<id>10004</id>
<alert>Password autocomplete</alert>
<desc>AUTOCOMPLETE attribute is not disabled in HTML FORM/INPUT element which contains password type input.  Passwords can be stored in browsers and retrieved</desc>
<solution>Turn off AUTOCOMPLETE attribute in form or individual input elements containing password:
AUTOCOMPLETE=&quot;OFF&quot;</solution>
<reference>http://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/autocomplete_ovr.asp</reference>
</alertitem>

<alertitem>
<id>10005</id>
<alert>Private IP disclosure</alert>
<desc>Private IP eg 10.x.x.x, 172.x.x.x, 192.168.x.x is found in the HTTP response body.  This can be used to attack internal system.</desc>
<solution>Remove the private IP address from the HTTP response body.</solution>
</alertitem>

<alertitem>
<id>10006</id>
<alert>Platform disclosure</alert>
<desc>Platform keyword may be disclosed.  Attacker can use this to focus on particular platform.</desc>
<solution>Remove comment indicating platform used.</solution>
</alertitem>

<alertitem>
<id>10007</id>
<alert>CRLF Injection</alert>
<desc>Cookie can be set via CRLF injection.  It may also be possible to set arbitrary HTTP response header.  In addition, by carefully crafting the injected response cross-site script, cache poisiong vulnerability may also exist.</desc>
<solution>Type check the submitted parameter carefully.  Do not allow CRLF to be injected by filtering CRLF.</solution>
<reference>http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf
http://webappfirewall.com/lib/crlf-injection.txt</reference>
</alertitem>

<alertitem>
<id>10008</id>
<alert>SSL Cipher Suite</alert>
<desc>This lists the cipher suites supported.</desc>
<solution>If there is any unnecessary cipher suite, disable it.</solution>
<reference>http://www.meer.net/~ericm/papers/ssl_servers.html</reference>
</alertitem>

<alertitem>
<id>10009</id>
<alert>Cipher suite without encryption</alert>
<desc>One or more of the cipher suite supported does not provide encryption.</desc>
<solution>Remove these cipher suite.</solution>
<reference>http://www.meer.net/~ericm/papers/ssl_servers.html#2.1</reference>
</alertitem>

<alertitem>
<id>10010</id>
<alert>Server header info</alert>
<desc>Web server or web application server header is obtained.</desc>
<solution></solution>
<reference></reference>
</alertitem>

<alertitem>
<id>10011</id>
<alert>Set-cookie header info</alert>
<desc>Cookie is set here.  If this is a session cookie, review the session creation mechanism.</desc>
<solution></solution>
<reference></reference>
</alertitem>

<alertitem>
<id>10012</id>
<alert>Session ID in URL rewrite</alert>
<desc>URL rewrite is used to track user session ID.  The session ID may be disclosed in referer header.  Besides, the session ID can be stored in browser history or server logs.</desc>
<solution>For secure content, put session ID in cookie.</solution>
<reference>. http://seclists.org/lists/webappsec/2002/Oct-Dec/0111.html
. http://seclists.org/lists/webappsec/2002/Oct-Dec/0111.html
</reference>
</alertitem>

<alertitem>
<id>10013</id>
<alert>Referer expose session ID</alert>
<desc>Hyperlink to other host name is found.  As session ID URL rewrite is used, it may be disclosed in referer header to external host.</desc>
<solution>This is a risk if the session ID is sensitive and the hyperlink refer to an external host.  For secure content, put session ID in secured session cookie.</solution>
<reference>. http://seclists.org/lists/webappsec/2002/Oct-Dec/0111.html
. http://seclists.org/lists/webappsec/2002/Oct-Dec/0111.html
</reference>
</alertitem>

<alertitem>
<id>10014</id>
<alert>Cipher suite with weak strength</alert>
<desc>Weak cipher suites are supported.</desc>
<solution>Enforce 128-bit SSL encryption.  Sometimes cipher suites of weak encryption strength are required for legacy export version of browser to step up to 128-bit SSL.</solution>
<reference>http://www.meer.net/~ericm/papers/ssl_servers.html#2.1</reference>
</alertitem>
<!--
**************************
20000 - 29999 checks below
**************************
-->

<alertitem>
<id>20000</id>
<alert>Cross site scripting</alert>
<desc>Cross-site scripting or HTML injection is possible.  Malicious script may be injected into the browser which appeared to be genuine content from the original site.  These scripts can be used to execute arbitrary code or steal customer sensitive information such as user password or cookies.

Very often this is in the form of a hyperlink with the injected script embeded in the query strings.  However, XSS is possible via FORM POST data, cookies, user data sent from another user or shared data retrieved from database.

Currently this check does not verify XSS from cookie or database.  They should be checked manually if the application retrieve database records from another user's input.</desc>

<solution>Do not trust client side input even if there is client side validation.  Sanitize potentially danger characters in the server side.  Very often filtering the &lt;, &gt;, &quot; characters prevented injected script to be executed in most cases.  However, sometimes other danger meta-characters such as &apos;, (, ), /, &amp;, ; etc are also needed.

In addition (or if these characters are needed), HTML encode meta-characters in the response.</solution>
<reference>The OWASP guide at http://www.owasp.org/documentation/guide
http://www.technicalinfo.net/papers/CSS.html
http://www.cgisecurity.org/articles/xss-faq.shtml
http://www.cert.org/tech_tips/malicious_code_FAQ.html
http://sandsprite.com/Sleuth/papers/RealWorld_XSS_1.html</reference>

</alertitem>

<alertitem>
<id>20001</id>
<alert>SQL injection</alert>
<desc>SQL injection is possible.  User parameters submitted will be formulated into a SQL query for database processing.  If the query is built by simple 'string concatenation', it is possible to modify the meaning of the query by carefully crafting the parameters.
Depending on the access right and type of database used, tampered query can be used to retrieve sensitive information from the database or execute arbitrary code.  MS SQL and PostGreSQL, which supports multiple statements, may be exploited if the database user right is high.

This can occur in URL query strings, POST paramters or even cookies.  Currently check on cookie is not supported by Paros.  You should check this manually as some blind SQL injection areas cannot be discovered by this check as well.</desc>
<solution>Do not trust client side input even if there is client side validation.  In general,
. If the input string is numeric, type check it.
. If the application used JDBC, use PreparedStatement or CallableStatement with parameters passed by &apos;?&apos;.
. If the application used ASP, use ADO Command Objects with strong type checking.
. If stored procedure or bind variables can be used, use it for parameter passing into query.  Do not just concatenate string into query in the stored procedure!
. Do not create dynamic SQL query by simple string concatentation.
. Use minimum database user privilege for the application.  This does not eliminate SQL injection but minimize its damage.  Eg if the application require reading one table only, grant such access to the application.  Avoid using 'sa' or 'db-owner'.</solution>

<reference>The OWASP guide at http://www.owasp.org/documentation/guide
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
For Oracle database, refer to http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf</reference>
</alertitem>

<alertitem>
<id>20002</id>
<alert>Error trace</alert>
<desc>Certain parameter caused error page or Java stacktrace to be displayed.  This indicated lack of exception handling and potential areas for further exploit.</desc>
<solution>Identify the cause of the error and fix it.  Do not trust client side input and enforece tight check in the server side.  Besides, catch the exception properly.  Use a generic 500 error page for internal server error.</solution>
</alertitem>

<alertitem>
<id>20003</id>
<alert>Perl command injection</alert>
<desc>Certain parameter may caused arbitrary Perl command to be executed.  This indicated lack of server side checking.</desc>
<solution>Do not trust client side input and enforece tight check in the server side.  Do not feed unchecked data into system(), exec(), back quote, eval() statements</solution>
<reference>http://www.perldoc.com/perl5.6/pod/perlsec.html</reference>
</alertitem>

<alertitem>
<id>20004</id>
<alert>Server Side Include injection</alert>
<desc>Certain parameter may caused Server Side Include to be executed.  This may allow database connection or arbitrary code to be executed</desc>
<solution>Do not trust client side input and enforece tight check in the server side.  Disable server side include.
. Refer to respective manual to disable Sever Side Include.
. Use least privilege to run your web server or application server.

For Apache, disable the following:
Options Indexes FollowSymLinks Includes
AddType application/x-httpd-cgi .cgi
AddType text/x-server-parsed-html .html
</solution>
<reference>http://www.carleton.ca/~dmcfet/html/ssi.html</reference>
</alertitem>

<alertitem>
<id>30000</id>
<alert>Exceeding long paramter</alert>
<desc>Exceeding long parameter is accepted.  It is possible to inject long (over 8192) char A&apos;s into the parameter and the server accepted in the HTTP responses.  This can be used to flood the application."</desc>
<solution>Restrict maximum field length accepted.</solution>
</alertitem>

<alertitem>
<id>30001</id>
<alert>Format string buffer overflow</alert>
<desc>By sending a long (over 8192) format string '%x%n' the server appeared to close the connection.  Manual check this again.</desc>
<solution>Check if format string was correctly handled.  Restrict maximum field length.</solution>
</alertitem>

</alerts>