Cross-Site Scripting vulnerabilities were verified as executing code on the web application. Cross-Site Scripting
occurs when dynamically generated web pages display user input, such as login information, that is not properly
validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on
the machine of any user that views the site. In this instance, the web application was vulnerable to an automatic
payload, meaning the user simply has to visit a page to make the malicious scripts execute. If successful, Cross-
Site Scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be
mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user
systems. Recommendations include implementing secure programming techniques that ensure proper filtration
of user-supplied data, and encoding all user supplied data to prevent inserted scripts being sent to end users in a
format that can be executed.
Execution: How to verify or exploit the issue.
View the attack string included with the request to check what to search for in the response. For instance, if
"(javascript:alert('XSS')" is submitted as an attack (or another scripting language), it will also appear as part of
the response. This indicates that the web application is taking values from the HTTP request parameters and
using them in the HTTP response without first removing potentially malicious data.
Implication: How this vulnerability affects you.
XSS can generally be subdivided into two categories: stored and reflected attacks. The main difference between
the two is in how the payload arrives at the server. Stored attacks are just that...in some form stored on the target
server, such as in a database, or via a submission to a bulletin board or visitor log. The victim will retrieve and
execute the attack code in his browser when a request is made for the stored information. Reflected attacks, on
the other hand, come from somewhere else. This happens when user input from a web client is immediately
included via server-side scripts in a dynamically generated web page. Via some social engineering, an attacker
can trick a victim, such as through a malicious link or "rigged" form, to submit information which will be altered to
include attack code and then sent to the legitimate server. The injected code is then reflected back to the user's
browser which executes it because it came from a trusted server. The implication of each kind of attack is the
same.
The main problems associated with successful Cross-Site Scripting attacks are:
Account hijacking - An attacker can hijack the user's session before the session cookie expires and
take actions with the privileges of the user who accessed the URL, such as issuing database queries
and viewing the results.
Malicious script execution - Users can unknowingly execute JavaScript, VBScript, ActiveX, HTML, or
even Flash content that has been inserted into a dynamically generated page by an attacker.
Worm propagation - With Ajax applications, XSS can propagate somewhat like a virus. The XSS
payload can autonomously inject itself into pages, and easily re-inject the same host with more XSS, all
of which can be done with no hard refresh. Thus, XSS can send multiple requests using complex HTTP
methods to propagate itself invisibly to the user.
Information theft - Via redirection and fake sites, attackers can connect users to a malicious server of
the attacker's choice and capture any information entered by the user.
Denial of Service - Often by utilizing malformed display requests on sites that contain a Cross-Site
Scripting vulnerability, attackers can cause a denial of service condition to occur by causing the host
site to query itself repeatedly .
Browser Redirection - On certain types of sites that use frames, a user can be made to think that he is
in fact on the original site when he has been redirected to a malicious one, since the URL in the
browser's address bar will remains the same. This is because the entire page isn't being redirected, just
the frame in which the JavaScript is being executed.
Manipulation of user settings - Attackers can change user settings for nefarious purposes.
For more detailed information on Cross-Site Scripting attacks, see the HP Cross-Site Scripting whitepaper.
Fix: How to remediate the issue.
For Development:
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output.
When validating user input, verify that it matches the strictest definition of valid input possible. For example, if a
certain parameter is supposed to be a number, attempt to convert it to a numeric data type in your programming
language.
PHP: intval("0".$_GET['q']);
ASP.NET: int.TryParse(Request.QueryString["q"], out val);
The same applies to date and time values, or anything that can be converted to a stricter type before being used.
When accepting other types of text input, make sure the value matches either a list of acceptable values (white-
listing), or a strict regular expression. If at any point the value appears invalid, do not accept it. Also, do not
attempt to return the value to the user in an error message.
Most server side scripting languages provide built in methods to convert the value of the input variable into
correct, non-interpretable HTML. These should be used to sanitize all input before it is displayed to the client.
PHP: string htmlspecialchars (string string [, int quote_style])
ASP.NET: Server.HTMLEncode (strHTML String)
When reflecting values into JavaScript or another format, make sure to use a type of encoding that is
appropriate. Encoding data for HTML is not sufficient when it is reflected inside of a script or style sheet. For
example, when reflecting data in a JavaScript string, make sure to encode all non-alphanumeric characters using
hex (\xHH) encoding.
If you have JavaScript on your page that accesses unsafe information (like location.href) and writes it to the page
(either with document.write, or by modifying a DOM element), make sure you encode data for HTML before
writing it to the page. JavaScript does not have a built-in function to do this, but many frameworks do. If you are
lacking an available function, something like the following will handle most cases:
s = s.replace(/&/g,'&').replace(/"/i,'"').replace(/</i,'<').replace(/>/i,'>').replace(/'/i,''')
Ensure that you are always using the right approach at the right time. Validating user input should be done as
soon as it is received. Encoding data for display should be done immediately before displaying it.
For Security Operations:
Server-side encoding, where all dynamic content is first sent through an encoding function where Scripting tags
will be replaced with codes in the selected character set, can help to prevent Cross-Site Scripting attacks.
Many web application platforms and frameworks have some built-in support for preventing Cross-Site Scripting.
Make sure that any built-in protection is enabled for your platform. In some cases, a misconfiguration could allow
Cross-Site Scripting. In ASP.NET, if a page's EnableViewStateMac property is set to False, the ASP.NET view
state can be used as a vector for Cross-Site Scripting.
An IDS or IPS can also be used to detect or filter out XSS attacks. Below are a few regular expressions that will
help detect Cross-Site Scripting.
Regex for a simple XSS attack:
/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix
The above regular expression would be added into a new Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-Site Scripting attempt";
flow:to_server,established; pcre:"/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i"; classtype:Web-application-
attack; sid:9000; rev:5;)
Paranoid regex for XSS attacks:
/((\%3C)|<)[^\n]+((\%3E)|>)/I
This signature simply looks for the opening HTML tag, and its hex equivalent, followed by one or more characters
other than the new line, and then followed by the closing tag or its hex equivalent. This may end up giving a few
false positives depending upon how your web application and web server are structured, but it is guaranteed to
catch anything that even remotely resembles a Cross-Site Scripting attack.
For QA:
Fixes for Cross-Site Scripting defects will ultimately require code based fixes. Read the the following links for
more information about manually testing your application for Cross-Site Scripting.
Reference Info:
OWASP Cross-Site Scripting Information
https://www.owasp.org/index.php/XSS
Microsoft
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985
Microsoft Anti-Cross Site Scripting Library
https://msdn.microsoft.com/en-us/security/aa973814.aspx
CERT
http://www.cert.org/advisories/CA-2000-02.html
Apache
http://httpd.apache.org/info/css-security/apache_specific.html
SecurityFocus.com
http://www.securityfocus.com/infocus/1768
Summary: Insecure Transport: Weak SSL CipherVulnerability ID: 11285
WebInspect has detected support for weak TLS/SSL ciphers on server https://zero.webappsecurity.com:443/ .
The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a mechanism to help
protect authenticity, confidentiality and integrity of the data transmitted between a client and web server. The
strength of this protection mechanism is determined by the authentication, encryption and hashing algorithms,
collectively known as a cipher suite, chosen for the transmission of sensitive information over the TLS/SSL
channel. Most Web servers support a range of such cipher suites of varying strengths. Using a weak cipher or an
encryption key of insufficient length, for example, could allow an attacker to defeat the protection mechanism and
steal or modify sensitive information.
If misconfigured, a web server could be manipulated into choosing weak cipher suites. Recommendations
include updating the web server configuration to always choose the strongest ciphers for encryption.
Execution: How to verify or exploit the issue.
Each weak cipher was enumerated by establishing an SSL connection with the target host and specifying the
cipher to test in the Client Hello message of the SSL handshake.
Implication: How this vulnerability affects you?
A weak encryption scheme can be subjected to brute force attacks that have a reasonable chance of succeeding
using current methods and resources. An attacker may be able to execute a man-in-the-middle attack which
would allow them to intercept, monitor and tamper with sensitive data.
Fix: How to remediate the issue.
Disable support for weak ciphers on the server. Weak ciphers are generally defined as:
Any cipher with key length less than 128 bits
Export-class cipher suites
NULL ciphers
Ciphers that support unauthenticated modes
Ciphers assessed at security strenghts below 112 bits
All RC4 ciphers
NOTE: Three-key Triple DES is assessed at a security strength of 112 bits and is an approved encryption
algorithm by NIST for use in SSL/TLS communications. Two-key Triple DES however, should be disabled as it is
assessed at a security strength of 80 bits and has been deprecated.
The following ciphers supported by the server are weak and should be disabled:
SSL2_RC4_128_WITH_MD5 (0x10080)
SSL2_RC4_128_EXPORT40_WITH_MD5 (0x20080)
SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x30080)
SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x40080)
SSL2_DES_64_CBC_WITH_MD5 (0x60040)
SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x700c0)
SSL_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
SSL_RSA_WITH_RC4_128_MD5 (0x4)
SSL_RSA_WITH_RC4_128_SHA (0x5)
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
SSL_RSA_WITH_DES_CBC_SHA (0x9)
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14)
SSL_DHE_RSA_WITH_DES_CBC_SHA (0x15)
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
TLS_RSA_WITH_RC4_128_MD5 (0x4)
TLS_RSA_WITH_RC4_128_SHA (0x5)
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
TLS_RSA_WITH_DES_CBC_SHA (0x9)
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14)
TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15)
The list above includes ciphers that enable conditions for FREAK (Factoring RSA Export Keys) attacks. FREAK
attacks could allow man-in-the-middle attackers to trick vulnerable clients into choosing weak export-class RSA
cipher to communicate with the target server, even if the client is not configured to offer one. This attack is
identified by CVE-2015-0204.
Following export-class ciphers should be removed from the target server configuration to prevent FREAK
attacks:
SSL_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
For Apache, modify the following lines in httpd.conf or ssl.conf:
o SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!DES:+HIGH:
+MEDIUM
For IIS, please refer to Microsoft Knowledge Base Articles:
o Article ID: 187498
o Article ID: 245030 and
o Security Guidance for IIS
o Article ID: 2868725
For other servers, please refer to vendor specific documentation.
The following ciphers supported by the server should provide adequate protection and may be left enabled:
SSL_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
PCI Security Standards Council:
PCI DSS v3.1
CVE
CVE-2013-2566
NIST
NIST Special Publication 800-131A
Microsoft:
Knowledge Base Article ID: 2868725
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
RC4:
New RC4 Attack
Summary: Insecure Transport: Weak SSL ProtocolVulnerability ID: 11286
WebInspect has detected support for weak SSL 2.0 protocol on the target server
https://zero.webappsecurity.com:443/.
The Transport Layer Security (TLS) protocol and the Secure Sockets Layer (SSL) protocol provide a protection
mechanism to ensure authenticity, confidentiality and integrity of the data transmitted between a client and web
server.
The TLS/SSL protocol has undergone various revisions resulting in periodic version updates. Each new revision
was designed to address the security weaknesses discovered in the previous versions. Use of insecure protocol
versions will weaken the strength of the transport protection and could allow an attacker to compromise, steal or
modify sensitive information. Correctly configuring the web server to use the most secure protocol is highly
recommended.
Having SSL 2.0 enabled on the server also makes it vulnerable to DROWN Attack. A server is shown to be
susceptible to DROWN if it either:
Allows SSL 2.0 connections or
Shares its private key with any other server that supports SSL 2.0
Simply supporting SSL 2.0 or sharing the server's private key with any another server that supports SSL 2.0
makes the target server vulnerable to DROWN. The vulnerability allows an attacker to decrypt any modern TLS
connection to eavesdrop and steal information exchanged between the clients and the target server. The attack
is identified by CVE-2016-0800.
Execution: How to verify or exploit the issue.
Each weak protocol was enumerated by establishing an SSL connection with the target host and specifying the
protocol to test in the Client Hello message of the SSL handshake.
The list of supported SSL protocols can be obtained by running the server analyzer tool from HP security toolkit
against the traget web application.
Implication: How this vulnerability affects you.
SSL 2.0 may exhibit following security weaknesses:
no protection against man-in-the-middle attacks
same key used for authentication and encryption
weak message authentication control
no protection against TCP connection closing
makes the server vulnerable to DROWN Attack
These properties can allow an attacker to intercept, modify and tamper with sensitive data.
Fix: How to remediate the issue.
1. Disable support for weak protocols on the server.
For Apache, modify the following lines in httpd.conf or ssl.conf:
o SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1
For IIS, please refer to Microsoft Knowledge Base Articles:
o 187498
o 245030
o Security Guidance for IIS
For other servers, please refer to vendor specific documentation.
2. Check SSL configurations on all servers that interact with the target server including email servers etc. to
ensure that SSL 2.0 is disabled on all of them. If a server has to be SSL 2.0 enabled then please ensure that
they do not share the same private key with any other server.
The following protocols supported by the server should provide adequate protection:
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
PCI Security Standards Council:
https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf
Microsoft:
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
The DROWN Attack
Summary: Insecure Transport: Weak SSL ProtocolVulnerability ID: 11378
WebInspect has detected support for SSL 3.0 protocol on the target server. The Secure Sockets Layer (SSL)
protocol provide a protection mechanism to better protect authenticity, confidentiality and integrity of the data
transmitted between a client and web server. The TLS/SSL protocol has undergone various revisions resulting in
periodic version updates. Each new revision was designed to address the security weaknesses discovered in the
previous versions. SSL 3.0 version is considered insecure because of lack of strong cipher suite support. It either
uses RC4 cipher, which is prone bias attacks or uses Cipher Block Chaining (CBC) mode cipher, which enables
condition for POODLE (Padding Oracle On Downgraded Legacy Encryption) attacks.
Use of insecure protocol versions will weaken the strength of the transport protection and could allow an attacker
to compromise, steal or modify sensitive information. Correctly configuring the web server to use the most secure
protocol is highly recommended.
Execution: How to verify or exploit the issue.
The list of supported SSL/TLS protocols can be obtained by running the server analyzer tool from HP security
toolkit supplied with HP WebInspect against the target server.
Implication: How this vulnerability affects you.
Weak TLS/SSL protocols may exhibit any or all of the following properties:
No protection against man-in-the-middle attacks
Same key used for authentication and encryption
Weak message authentication control
No protection against TCP connection closing
These properties can allow an attacker to intercept, modify and tamper with sensitive data.
Fix: How to remediate the issue.
Disable support for the SSL 3.0 protocol on the server. Instead, TLSv1.1 and above should be used.
For Apache, modify the following lines in the server configuration:
o SSLProtocol ALL –SSLv2 -SSLv3 -TLSv1
For Nginx, modify the following lines in server configuration:
o ssl_protocols TLSv1.1 TLSv1.2;
For IIS, please refer to Microsoft Knowledge Base Articles:
o https://technet.microsoft.com/library/security/3009008
For other servers, please refer to vendor specific documentation:
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
PCI Security Standards Council:
https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf
Microsoft:
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
CVE-2014-3566
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
This POODLE bites: exploiting the SSL 3.0 fallback
https://www.openssl.org/~bodo/ssl-poodle.pdf
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00l
Summary: Insecure Transport: Weak SSL ProtocolVulnerability ID: 11395
The Transport Layer Security (TLS) protocol provides a protection mechanism to better protect authenticity,
confidentiality and integrity of the data transmitted between a client and a web server. The TLS protocol has
undergone various revisions resulting in periodic version updates. Each revision tries to address security
weakness in prior versions and incorporate support for the latest in security measures. It is strongly
recommended to use the latest version of the available protocol, whenever possible.
TLS 1.0 is considered insecure as it lacks support for strong ciphersuites and is known to be plagued by several
known vulnerabilities. It either uses RC4 cipher, which is prone to bias attacks or uses Cipher Block Chaining
(CBC) mode cipher, which enables condition for POODLE (Padding Oracle On Downgraded Legacy Encryption)
attacks.
NIST Special Publication 800-52 Revision 1 no longer considers TLS 1.0 as strong cryptography. TLS 1.0 is also
no longer in compliance with PCI DSS v3.1 requirements. PCI does not consider TLS 1.0 to be adequate to
protect cardholder data and has deprecated its use starting June 2016.
Update: PCI DSS has extended deadline for migration to TLS1.1 or above to June 30, 2018. However, an
early migration is recommended to ensure security of your data and applications.
Use of insecure protocol versions will weaken the strength of the transport protection and could allow an attacker
to compromise, steal or modify sensitive information. Configuring the web server to use the most secure protocol,
TLS 1.1 or TLS 1.2 is highly recommended.
Implication: How this vulnerability affects you.
Use of a weak protocol such as TLS 1.0 leaves the connection vulnerable to man-in-the-middle attacks. This
would allow the attacker to read and modify data on a secure TLS connection, thus compromising user security
and privacy. Its use would also limit the use of strong cipher suites that help protect data integrity and
confidentiality.
Fix: How to remediate the issue.
Disable support for the TLS 1.0 protocol on the server. Both NIST 800-52 and PCI DSS v3.1 strongly
recommend upgrade to the latest version of TLS available, TLS 1.2. Or, at a minimum an upgrade to TLS 1.1.
For Apache, modify the following lines in the server configuration
o SSLProtocol ALL –SSLv2 -SSLv3 -TLSv1
For Nginx, modify the following lines in server configuration:
o ssl_protocols TLSv1.1 TLSv1.2;
For IIS, please refer to Microsoft Knowledge Base Articles:
o https://technet.microsoft.com/library/security/3009008
For other servers, please refer to vendor specific documentation.
Reference Info:
OWASP:
Transport Layer Protection Cheat Sheet
NIST:
NIST SP 800-52 Revision 1
PCI Security Standards Council:
PCI DSS v3.1
Migrating from SSL and Early TLS
PCI SSC FAQ on impending revisions to PCI DSS, PA-DSS to address SSL protocol vulnerability
Microsoft:
Knowledge Base Article ID: 187498
Knowledge Base Article ID: 245030
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
CVE-2014-8730
CVE-2014-8730
POODLE Vulnerability Expands Beyond SSLv3 to TLS 1.0 and 1.1
https://www.globalsign.com/en/blog/poodle-vulnerability-expands-beyond-sslv3-to-tls/
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00l
Summary: Insecure Transport: Weak SSL CipherVulnerability ID: 11480
Logjam is an attack against the Diffie-Hellman key exchange protocol used in TLS. Diffie-Hellman is a key
exchange protocol used within SSL/TLS connections to securely exchange cryptographic keys over a public
channel.The Logjam attack affects all servers that support export grade DHE (DHE_EXPORT) ciphersuites. It
attacks a flaw in the TLS protocol that allows the attacker to downgrade a TLS connection using a non
DHE_EXPORT ciphersuite to a vulnerable connection using a 512 bit DHE_EXPORT ciphersuite. This enables a
man in the middle attacker to easily decrypt and eavesdrop on the TLS connection.
WebInspect has determined that the target server is vulnerable to Logjam attack as it supports the following
DHE_EXPORT ciphers:
Execution: How to verify or exploit the issue.
A list of supported ciphers by this server can be obtained by running ServerAnalyzer tool from the WebInspect
toolkit. Note the presence of “DHE_EXPORT“ in the list of supported ciphersuites.
Implication: How this vulnerability affects you.
A downgraded TLS connection allows the Logjam attacker to easily read and modify any data passed over that
TLS connection.
Fix: How to remediate the issue.
Disable support for cipher suites using DHE_EXPORT key exchange.
o For Apache - Modify SSLCipherSuite parameter to disable all DHE_EXPORT ciphers.
o For Ngnix - Modify ssl_ciphers in server configuration to disable all DHE_EXPORT ciphers.
o For IIS - Please refer to the following knowledge base article :
https://support.microsoft.com/en-us/kb/245030
Enable support for Elliptic-Curve Diffie-Hellman (ECDHE) key exchange.
Reference Info:
1. CVE-2015-4000
2. Schneier on Security
3. The Logjam Attack
4. Logjam: TLS vulnerabilities(CVE-2015-4000)