ZAP Scanning Report

Una iniezione SQL potrebbe essere possibile.

Non fidarti dell'input utente anche se viene effettuata la validazione client side. In linea generale,

controlla il tipo di tutti i dati a lato server.

Se l'applicazione utilizza JDBC, usa PreparedStatement o CallableStatement con parametri passati via '?'.

Se l'applicazione utilizza ASP, usa gli Oggetti ADO Command con forte controllo tipizzato e query parametrizzate.

Se lato database possono essere utilizzate Stored Procedures, utilizzale. *Non* concatenare stringhe in query nelle stored procedure, o utilizzare 'exec', 'exec immediate', o istruzioni equivalenti!

Non creare query SQL dinamiche utilizzando la semplice concatenazione delle stringhe.

Sanifica tutti i dati ricevuti dal client.

Adotta una 'whitelist' di caratteri permessi, o una 'blacklist' di caratteri non consentiti nell'input utente.

Adotta il principio del privilegio minimo utilizzando l'utente del database con il minor numero di privilegi possibili.In particolare, evitare di utilizzare il 'sa' o gli utenti 'db-owner'. Questo non eliminerà eventuali SQL injection, ma ridurrà al minimo il loro impatto.

Concedi nel database l'accesso minimo necessario al funzionamento dell'applicazione.

I risultati della pagina originale sono stati replicati con successo utilizzando l'espressione [5-2] come valore del parametro. Il valore del parametro modificato è stato rimosso dall'output HTML a scopo di confronto

https://www.owasp.org/index.php/Top_10_2010-A1

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Based on passive analysis of the response, insecure component nginx 1.4.1 appears to be in use.

The highest noted CVSS rating for this product version is 7,5.

In total, 3 vulnerabilities were noted.

Some Linux distributions such as Red Hat employ the practice of retaining old version numbers when security fixes are "backported".

These cases are noted as "False Positives", but should be manually verified.

Upgrade from nginx 1.4.1 to the latest stable version of the product.

Use a package manager and package management policies and procedures to manage the installed versions of software packages.

CVE: CVE-2013-4547

CVSS: 7.5

CVE: CVE-2014-0133

CVSS: 5.1

CVE: CVE-2014-3616

CVSS: 3.75

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-4547

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-0133

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-3616

A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The underlying cause is application functionality using predictable URL/form actions in a repeatable way. The nature of the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting (XSS) exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session riding, confused deputy, and sea surf.

CSRF attacks are effective in a number of situations, including:

* The victim has an active session on the target site.

* The victim is authenticated via HTTP auth on the target site.

* The victim is on the same local network as the target site.

CSRF has primarily been used to perform an action against a target site using the victim's privileges, but recent techniques have been discovered to disclose information by gaining access to the response. The risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-origin policy.

Phase: Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, use anti-CSRF packages such as the OWASP CSRFGuard.

Phase: Implementation

Ensure that your application is free of cross-site scripting issues, because most CSRF defenses can be bypassed using attacker-controlled script.

Phase: Architecture and Design

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330).

Note that this can be bypassed using XSS.

Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.

Note that this can be bypassed using XSS.

Use the ESAPI Session Management control.

This control includes a component for CSRF.

Do not use the GET method for any request that triggers a state change.

Phase: Implementation

Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.

http://projects.webappsec.org/Cross-Site-Request-Forgery

http://cwe.mitre.org/data/definitions/352.html

Based on passive analysis of the response, insecure component PHP 5.3.10 appears to be in use.

The highest noted CVSS rating for this product version is 10.

In total, 28 vulnerabilities were noted.

Some Linux distributions such as Red Hat employ the practice of retaining old version numbers when security fixes are "backported".

These cases are noted as "False Positives", but should be manually verified.

Upgrade from PHP 5.3.10 to the latest stable version of the product.

Use a package manager and package management policies and procedures to manage the installed versions of software packages.

CVE: CVE-2012-2688

CVSS: 10.0

CVE: CVE-2012-1823

CVSS: 7.5

CVE: CVE-2012-2311

CVSS: 7.5

CVE: CVE-2012-2386

CVSS: 7.5

CVE: CVE-2013-1635

CVSS: 7.5

CVE: CVE-2013-6420

CVSS: 7.5

CVE: CVE-2014-9427

CVSS: 7.5

CVE: CVE-2011-4718

CVSS: 6.8

CVE: CVE-2012-0831

CVSS: 6.8

CVE: CVE-2013-4113

CVSS: 6.8

CVE: CVE-2012-1172

CVSS: 5.8

CVE: CVE-2012-1171

CVSS: 5.0

CVE: CVE-2012-2336

CVSS: 5.0

CVE: CVE-2012-3365

CVSS: 5.0

CVE: CVE-2012-6113

CVSS: 5.0

CVE: CVE-2013-1643

CVSS: 5.0

CVE: CVE-2013-2110

CVSS: 5.0

CVE: CVE-2013-4635

CVSS: 5.0

CVE: CVE-2014-0237

CVSS: 5.0

CVE: CVE-2014-0238

CVSS: 5.0

CVE: CVE-2011-1398

CVSS: 4.3

CVE: CVE-2012-2143

CVSS: 4.3

CVE: CVE-2013-1824

CVSS: 4.3

CVE: CVE-2013-4248

CVSS: 4.3

CVE: CVE-2014-2497

CVSS: 4.3

CVE: CVE-2014-5459

CVSS: 3.6

CVE: CVE-2012-3450

CVSS: 2.6

CVE: CVE-2014-4721

CVSS: 2.6

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-2688

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-1823

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-2311

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-2386

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-1635

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-6420

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-9427

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2011-4718

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-0831

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-4113

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-1172

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-1171

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-2336

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-3365

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-6113

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-1643

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-2110

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-4635

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-0237

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-0238

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2011-1398

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-2143

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-1824

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2013-4248

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-2497

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-5459

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2012-3450

http://www.cvedetails.com/cve-details.php?cve_id=CVE-2014-4721

Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.

When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.

Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.

Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

Phase: Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design

Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation

For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

http://projects.webappsec.org/Cross-Site-Scripting

http://cwe.mitre.org/data/definitions/79.html

SQL injection potrebbe essere possibile

Non ci si fidi dell'input utente anche se viene effettuata la validazione client side. In linea generale,

si controlli il tipo di tutti i dati a lato server.

Se l'applicazione utilizza JDBC, si usi PreparedStatement o CallableStatement con parametri passati via '?'.

Se l'applicazione utilizza ASP, si usino gli Oggetti ADO Command con controllo tipizzato e query parametrizzate.

Se lato database possono essere utilizzate Stored Procedures, le si usino. Non si concatenino stringhe in query nelle stored procedure, o utilizzi 'exec', 'exec immediate', o istruzioni equivalenti!

Non si creino query SQL dinamiche utilizzando la semplice concatenazione delle stringhe.

Si sanitizzino tutti i dati ricevuti dal client.

Si adotti una 'whitelist' di caratteri permessi, o una 'blacklist' di caratteri non consentiti nell'input utente.

Si adotti il principio del privilegio minimo utilizzando l'utente del database con il minor numero di privilegi possibili.In particolare, si eviti di utilizzare il 'sa' o gli utenti 'db-owner'. Questo non eliminerà eventuali SQL injection, ma ridurrà al minimo il loro impatto.

Si conceda nel database l'accesso minimo necessario al funzionamento dell'applicazione.

Il tempo di query è controllabile tramite il valore del parametro [ZAP' / sleep(15) / '], che ha causato l'impiego di [15.069] millisecondi per la richiesta, quando la query originale non modificata con valore [ZAP] ha impiegato [74] millisecondi

https://www.owasp.org/index.php/Top_10_2010-A1

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Remote File Include (RFI) is an attack technique used to exploit "dynamic file include" mechanisms in web applications. When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code.

Almost all web application frameworks support file inclusion. File inclusion is mainly used for packaging common code into separate files that are later referenced by main application modules. When a web application references an include file, the code in this file may be executed implicitly or explicitly by calling specific procedures. If the choice of module to load is based on elements from the HTTP request, the web application might be vulnerable to RFI.

An attacker can use RFI for:

* Running malicious code on the server: any code in the included malicious files will be run by the server. If the file include is not executed using some wrapper, code in include files is executed in the context of the server user. This could lead to a complete system compromise.

* Running malicious code on clients: the attacker's malicious code can manipulate the content of the response sent to the client. The attacker can embed malicious code in the response that will be run by the client (for example, Javascript to steal the client session cookies).

PHP is particularly vulnerable to RFI attacks due to the extensive use of "file includes" in PHP programming and due to default server configurations that increase susceptibility to an RFI attack.

Phase: Architecture and Design

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.

Phases: Architecture and Design; Operation

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by your software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

For PHP, the interpreter offers restrictions such as open basedir or safe mode which can make it more difficult for an attacker to escape out of the application. Also consider Suhosin, a hardened PHP extension, which includes various options that disable some of the more dangerous PHP features.

Phase: Implementation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.

Phases: Architecture and Design; Operation

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.

This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce your attack surface.

Phases: Architecture and Design; Implementation

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.

http://projects.webappsec.org/Remote-File-Inclusion

http://cwe.mitre.org/data/definitions/98.html

E' possibile una contraffazione della richiesta cross-site basata su Flash/Silverlight, a causa di un errore di configurazione sul server web.

Configurare il file crossdomain.xml per limitare l'elenco dei domini che sono autorizzati a fare richieste di lettura cross-domain a questo server web utilizzando <allow-access-from domain="example.com" >. Si dovrebbe garantire accesso a "*" (tutti i domini) se si è certi che questo servizio non ospita nessun dato ad accesso controllato, personale o privato.

Il server web permette richieste con intento malevolo di lettura cross-domain provenienti da componenti Flash/Silverlight serviti da qualsiasi dominio di terze parti, a questo dominio. Se lutente vittima ha effettuato laccesso a questo servizio, le richieste di lettura dannose vengono elaborate utilizzando i privilegi della vittima e possono portare alla compromissione dei dati da questo servizio da parte di un sito web di terze parti non autorizzate, tramite browser della vittima. Ciò è probabilmente un problema se è in uso unimplementazione di sessione basato su Cookie .

http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html http://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/CrossDomain_PolicyFile_Specification.pdf http://msdn.microsoft.com/en-US/library/cc197955%28v=vs.95%29.aspx http://msdn.microsoft.com/en-us/library/cc838250%28v=vs.95%29.aspx

Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.

When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.

Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.

Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

Phase: Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design

Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation

For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

Rilevato con BASSA confidenza dato che il content-type non è HTML

http://projects.webappsec.org/Cross-Site-Scripting

http://cwe.mitre.org/data/definitions/79.html

L'intestazione X-Frame-Options non è inclusa nella risposta HTTP per proteggersi da attacchi 'ClickJacking'.

Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).

http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

Unspecified form action: HTTP parameter override attack potentially possible. This is a known problem with Java Servlets but other platforms may also be vulnerable.

All forms must specify the action URL.

http://download.oracle.com/javaee-archive/servlet-spec.java.net/jsr340-experts/att-0317/OnParameterPollutionAttacks.pdf

The web/application server is leaking version information via the "Server" HTTP response header. Access to such information may facilitate attackers identifying other vulnerabilities your web/application server is subject to.

Ensure that your web server, application server, load balancer, etc. is configured to suppress the "Server" header or provide generic details.

http://httpd.apache.org/docs/current/mod/core.html#servertokens

http://msdn.microsoft.com/en-us/library/ff648552.aspx#ht_urlscan_007

http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx

http://www.troyhunt.com/2012/02/shhh-dont-let-your-response-headers.html

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP provides a set of standard HTTP headers that allow website owners to declare approved sources of content that browsers should be allowed to load on that page — covered types are JavaScript, CSS, HTML frames, fonts, images and embeddable objects such as Java applets, ActiveX, audio and video files.

Ensure that your web server, application server, load balancer, etc. is configured to set the Content-Security-Policy header, to achieve optimal browser support: "Content-Security-Policy" for Chrome 25+, Firefox 23+ and Safari 7+, "X-Content-Security-Policy" for Firefox 4.0+ and Internet Explorer 10+, and "X-WebKit-CSP" for Chrome 14+ and Safari 6+.

https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy

https://www.owasp.org/index.php/Content_Security_Policy

http://www.w3.org/TR/CSP/

http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

http://caniuse.com/#feat=contentsecuritypolicy

http://content-security-policy.com/

L'intestazione Anti-MIME-Sniffing nell'impostazione X-Content-Type-Options non era impostata su 'nosniff'. Questo permette alle vecchie versioni di Internet Explorer e Chrome di eseguire analisi MIME-sniffing sul corpo della risposta, potenzialmente causando che il corpo della risposta venga interpretato e visualizzato come un tipo di contenuto diverso dal tipo dichiarato. Versioni attuali (inizio 2014) e precedenti di Firefox useranno il tipo di contenuto dichiarato (se uno è impostato), piuttosto che eseguire analisi MIME.

Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.

If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing.

This issue still applies to error type pages (401, 403, 500, etc) as those pages are often still affected by injection issues, in which case there is still concern for browsers sniffing pages away from their actual content type.

At "High" threshold this scanner will not alert on client or server error responses.

http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx

https://www.owasp.org/index.php/List_of_useful_HTTP_headers

Protezione XSS del Web Browser non è abilitata, o è disabilitata dalla configurazione dell'intestazione di risposta HTTP 'X-XSS-Protection' sul server web

Assicurarsi che il filtro XSS del web browser sia abilitato, impostando l'intestazione di risposta HTTP X-XSS-Protection a '1'.

L'intestazione di risposta HTTP X-XSS-Protection consente al server web attivare o disattivare il meccanismo di protezione del browser web XSS. I valori seguenti avrebbe tentato di attivarla:

X-XSS-Protection: 1; mode = block

X-XSS-Protection: 1; report = http://www.example.com/xss

i seguenti valori lo disabiliterebbero:

X-XSS-Protection: 0

L'intestazione di risposta HTTP X-XSS-Protection è attualmente supportata su Internet Explorer, Chrome e Safari (WebKit). Si noti che questo avviso viene generato solo se il corpo della risposta potenzialmente potrebbe contenere un payload XSS (con un tipo di contenuto basato su testo , con una lunghezza diversa da zero).

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/

The web/application server is leaking information via one or more "X-Powered-By" HTTP response headers. Access to such information may facilitate attackers identifying other frameworks/components your web application is reliant upon and the vulnerabilities such components may be subject to.

Ensure that your web server, application server, load balancer, etc. is configured to suppress "X-Powered-By" headers.

http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx

http://www.troyhunt.com/2012/02/shhh-dont-let-your-response-headers.html

Nessun Token Anti-CSRF è stato trovato nel form HTML.

A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The underlying cause is application functionality using predictable URL/form actions in a repeatable way. The nature of the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting (XSS) exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session riding, confused deputy, and sea surf.

CSRF attacks are effective in a number of situations, including:

* The victim has an active session on the target site.

* The victim is authenticated via HTTP auth on the target site.

* The victim is on the same local network as the target site.

CSRF has primarily been used to perform an action against a target site using the victim's privileges, but recent techniques have been discovered to disclose information by gaining access to the response. The risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-origin policy.

Phase: Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, use anti-CSRF packages such as the OWASP CSRFGuard.

Phase: Implementation

Ensure that your application is free of cross-site scripting issues, because most CSRF defenses can be bypassed using attacker-controlled script.

Phase: Architecture and Design

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330).

Note that this can be bypassed using XSS.

Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.

Note that this can be bypassed using XSS.

Use the ESAPI Session Management control.

This control includes a component for CSRF.

Do not use the GET method for any request that triggers a state change.

Phase: Implementation

Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.

Nessun Token Anti-CSRF [anticsrf, CSRFToken, __RequestVerificationToken, csrfmiddlewaretoken, authenticity_token, OWASP_CSRFTOKEN, anoncsrf] è stato trovato nel seguente form HTML: [Form 2: "searchFor" "goButton" ].

http://projects.webappsec.org/Cross-Site-Request-Forgery

http://cwe.mitre.org/data/definitions/352.html

The AUTOCOMPLETE attribute is not disabled on an HTML FORM/INPUT element containing password type input. Passwords may be stored in browsers and retrieved.

Turn off the AUTOCOMPLETE attribute in forms or individual input elements containing password inputs by using AUTOCOMPLETE='OFF'.

http://www.w3schools.com/tags/att_input_autocomplete.asp

https://msdn.microsoft.com/en-us/library/ms533486%28v=vs.85%29.aspx

Base64 encoded data was disclosed by the application/web server

Manually confirm that the Base64 data does not leak sensitive information, and that the data cannot be aggregated/used to exploit other vulnerabilities.

\x000fn�\x000c\x001e��\x0001:\x000f�uq���\x001f>�9�~x�M4

https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure

http://projects.webappsec.org/w/page/13246936/Information%20Leakage

The response contents are storable by caching components such as proxy servers, and may be retrieved directly from the cache, rather than from the origin server by the caching servers, in response to similar requests from other users. If the response data is sensitive, personal or user-specific, this may result in sensitive information being leaked. In some cases, this may even result in a user gaining complete control of the session of another user, depending on the configuration of the caching components in use in their environment. This is primarily an issue where "shared" caching servers such as "proxy" caches are configured on the local network. This configuration is typically found in corporate or educational environments, for instance.

Validate that the response does not contain sensitive, personal or user-specific information. If it does, consider the use of the following HTTP response headers, to limit, or prevent the content being stored and retrieved from the cache by another user:

Cache-Control: no-cache, no-store, must-revalidate, private

Pragma: no-cache

Expires: 0

This configuration directs both HTTP 1.0 and HTTP 1.1 compliant caching servers to not store the response, and to not retrieve the response (without validation) from the cache, in response to a similar request.

In the absence of an explicitly specified caching lifetime directive in the response, a liberal lifetime heuristic of 1 year was assumed. This is permitted by rfc7234.

https://tools.ietf.org/html/rfc7234

https://tools.ietf.org/html/rfc7231

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html (obsoleted by rfc7234)

The response contents are not storable by caching components such as proxy servers. If the response does not contain sensitive, personal or user-specific information, it may benefit from being stored and cached, to improve performance.

The content may be marked as storable by ensuring that the following conditions are satisfied:

The request method must be understood by the cache and defined as being cacheable ("GET", "HEAD", and "POST" are currently defined as cacheable)

The response status code must be understood by the cache (one of the 1XX, 2XX, 3XX, 4XX, or 5XX response classes are generally understood)

The "no-store" cache directive must not appear in the request or response header fields

For caching by "shared" caches such as "proxy" caches, the "private" response directive must not appear in the response

For caching by "shared" caches such as "proxy" caches, the "Authorization" header field must not appear in the request, unless the response explicitly allows it (using one of the "must-revalidate", "public", or "s-maxage" Cache-Control response directives)

In addition to the conditions above, at least one of the following conditions must also be satisfied by the response:

It must contain an "Expires" header field

It must contain a "max-age" response directive

For "shared" caches such as "proxy" caches, it must contain a "s-maxage" response directive

It must contain a "Cache Control Extension" that allows it to be cached

It must have a status code that is defined as cacheable by default (200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501).

https://tools.ietf.org/html/rfc7234

https://tools.ietf.org/html/rfc7231

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html (obsoleted by rfc7234)

The response appears to contain suspicious comments which may help an attacker.

Remove all comments that return information that may help an attacker and fix any underlying problems they refer to.

<script type="text/javascript">

var httpreq = null;

function SetContent(XML) {

var items = XML.getElementsByTagName('items').item(0).getElementsByTagName('item');

var inner = '<ul>';

for(i=0; i<items.length; i++){

inner = inner + '<li><a href="javascript:getInfo(\'' + items[i].attributes.item(0).value + '\', \'' + items[i].attributes.item(1).value + '\')">' + items[i].firstChild.nodeValue + '</a></li>';

}

inner = inner + '</ul>'

cd = document.getElementById('contentDiv');

cd.innerHTML = inner;

id = document.getElementById('infoDiv');

id.innerHTML = '';

}

function httpCompleted() {

if (httpreq.readyState==4 && httpreq.status==200) {

SetContent(httpreq.responseXML);

httpreq = null;

}

}

function SetInfo(XML) {

var ii = XML.getElementsByTagName('iteminfo').item(0);

var inner = '';

inner = inner + '

<strong>' + ii.getElementsByTagName('name').item(0).firstChild.nodeValue + '</strong>

pict = ii.getElementsByTagName('picture');

if(pict.length>0){

inner = inner + '<img src="../showimage.php?file=' + pict.item(0).firstChild.nodeValue + '"/>';

}

descs = ii.getElementsByTagName('description');

for (i=0; i<descs.length; i++){

inner = inner + '

' + descs.item(i).firstChild.nodeValue + '

}

id = document.getElementById('infoDiv');

id.innerHTML = inner;

}

function httpInfoCompleted() {

if (httpreq.readyState==4 && httpreq.status==200) {

SetInfo(httpreq.responseXML);

httpreq = null;

}

}

function loadSomething(what) {

getHttpRequest();

httpreq.open('GET', what, true);

httpreq.send('');

}

function getInfo(where, which) {

getHttpRequest();

httpreq.onreadystatechange = httpInfoCompleted;

if (where=='infotitle'){

httpreq.open('POST', where+'.php', true);

httpreq.setRequestHeader('content-type', 'application/x-www-form-urlencoded');

httpreq.send('id='+which);

}

else {

httpreq.open('GET', where+'.php?id='+which, true);

httpreq.send('');

}

}

function xmlCompleted () {

if (httpreq.readyState==4 && httpreq.status==200) {

xd = document.getElementById('xmlDiv');

xd.innerHTML = httpreq.responseText;

httpreq = null;

}

}

function sendXML () {

getHttpRequest();

httpreq.onreadystatechange = xmlCompleted;

httpreq.open('POST', 'showxml.php');

httpreq.setRequestHeader('content-type', 'text/xml');

httpreq.send('<xml><node name="nodename1">nodetext1</node><node name="nodename2">nodetext2</node></xml>');

}

function getHttpRequest() {

// free the curent one

if (httpreq!=null){

httpreq.abort();

httpreq = null;

}

if( window.XMLHttpRequest ) {

httpreq = new XMLHttpRequest();

if (httpreq.overrideMimeType) {

httpreq.overrideMimeType('text/xml');

}

} else if(ActiveXObject) {

httpreq = new ActiveXObject("Msxml2.XMLHTTP");

}

httpreq.onreadystatechange = httpCompleted;

}

function SetMyCookie() {

document.cookie = "mycookie=3";

alert('A cookie was set by JavaScript.');

}

</script>

This check looks at user-supplied input in query string parameters and POST data to identify where certain HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.

Validate all input and sanitize output it before writing to any HTML attributes.

User-controlled HTML attribute values were found. Try injecting special characters to see if XSS might be possible. The page at the following URL:

http://testphp.vulnweb.com/search.php?test=query

appears to include user input in:

a(n) [input] tag [value] attribute

The user input found was:

goButton=go

The user-controlled value was:

go

http://websecuritytool.codeplex.com/wikipage?title=Checks#user-controlled-html-attribute