Pantallas escaneo Sitio Web

Cross-Site Scripting vulnerabilities w ere verified as executing code on the w eb application. Cross-Site Scripting
occurs w hen dynamically generated w eb pages display user input, such as login information, that is not properly
validated, allow ing an attacker to embed malicious scripts into the generated page and then execute the script on
the machine of any user that view s the site. In this instance, the w eb application w as 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 w ith the request to check w hat to search for in the response. For instance, if

"(javascript:alert('XSS')" is submitted as an attack (or another scripting language), it w ill also appear as part of the
response. This indicates that the w eb application is taking values from the HTTP request parameters and using
them in the HTTP response w ithout first removing potentially malicious data.
Implication:
How this vulnerability affects you.
XSS can generally be subdivided into tw o categories: stored and reflected attacks. The main difference betw een
the tw o 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 w ill retrieve and
execute the attack code in his brow ser w hen a request is made for the stored information. Reflected attacks, on
the other hand, come from somew here else. This happens w hen user input from a w eb client is immediate ly
included via server-side scripts in a dynamically generated w eb page. Via some social engineering, an attacker
can trick a victim, such as through a malicious link or "rigged" form, to submit information w hich w ill be altered to
include attack code and then sent to the legitimate server. The injected code is then reflected back to the user's
brow ser w hich executes it because it came from a trusted server. The implication of each kind of attack is the
same.
The main problems associated w ith successful Cross-Site Scripting attacks are:
 Account hijacking - An attacker can hijack the user's session before the session cookie expires and take
actions w ith the privileges of the user w ho accessed the URL, such as issuing database queries and
view ing the results.
 Malicious script execution - Users can unknow ingly 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 somew hat like a virus. The XSS payload
can autonomously inject itself into pages, and easily re-inject the same host w ith more XSS, all of w hich
can be done w ith 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 .
 Brow ser 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 w hen he has been redirected to a malicious one, since the URL in the brow ser's
address bar w ill remains the same. This is because the entire page isn't being redirected, just the frame
in w hich 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 w hitepaper.
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 (w hite-
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 w hen it is reflected inside of a script or style sheet. For example, w hen
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 w rites it to the page
(either w ith document.w rite, or by modifying a DOM element), make sure you encode data for HTML before w riting
it to the page. JavaScript does not have a built-in function to do this, but many framew orks do. If you are lacking
an available function, something like the follow ing w ill handle most cases:
s = s.replace(/&/g,'&').replace(/"/i,'"').replace(/</i,'<').replace(/>/i,'>').replace(/'/i,''')

Ensure that you are alw ays 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, w here all dynamic content is first sent through an encoding function w here Scripting tags
w ill be replaced w ith codes in the selected character set, can help to prevent Cross-Site Scripting attacks.
Many w eb application platforms and framew orks 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 EnableView StateMac 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 w ill
help detect Cross-Site Scripting.
Regex for a simple XSS attack:
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
The above regular expression w ould be added into a new Snort rule as follow s:
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, follow ed by one or more characters
other than the new line, and then follow ed by the closing tag or its hex equivalent. This may end up giving a few
false positives depending upon how your w eb application and w eb 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 w ill ultimately require code based fixes. Read the the follow ing 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 Cipher
Vulnerability ID: 11285
WebInspect has detected support for w eak 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 betw een a client and w eb server. The
strength of this protection mechanism is determined by the authentication, encryption and hashing algorithms,
collectively know n 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 w eakcipher 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 w eb server could be manipulated into choosing w eak cipher suites. Recommendations include
updating the w eb server configuration to alw ays choose the strongest ciphers for encryption.
Execution:
Each w eak cipher w as enumerated by establishing an SSL connection w ith 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 w eak 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 w hich w ould
allow them to intercept, monitor and tamper w ith sensitive data.
Fix:
Disable support for w eak ciphers on the server. Weak ciphers are generally defined as:
 Any cipher w ith 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. Tw o-key Triple DES how ever, should be disabled as it is assessed
at a security strength of 80 bits and has been deprecated.
The follow ing ciphers supported by the server are w eak and should be disabled:
 SSL2_RC4_128_WITH_M D5 (0x10080)
 SSL2_RC4_128_EXPORT40_WITH_MD5 (0x20080)
 SSL2_RC2_CBC_128_CBC_WITH_M D5 (0x30080)
 SSL2_RC2_CBC_128_CBC_WITH_M D5 (0x40080)
 SSL2_DES_64_CBC_WITH_M D5 (0x60040)
 SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x700c0)
 SSL_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
 SSL_RSA_WITH_RC4_128_M D5 (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_M D5 (0x3)
 TLS_RSA_WITH_RC4_128_M D5 (0x4)
 TLS_RSA_WITH_RC4_128_SHA (0x5)
 TLS_RSA_EXPORT_WITH_RC2_CBC_40_M D5 (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 w eak export-class RSA
cipher to communicate w ith the target server, even if the client is not configured to offer one. This attack is identified
by CVE-2015-0204.
Follow ing 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_M D5 (0x3)
 TLS_RSA_EXPORT_WITH_RC2_CBC_40_M D5 (0x6)
 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
 For Apache, modify the follow ing 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 Know ledge 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 follow ing 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
Security Guidance for IIS
Apache:
SSL/TLS Strong Encryption: FAQ
RC4:
New RC4 Attack
Summary: Insecure Transport: Weak SSL Protocol
WebInspect has detected support for w eak 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 betw een a client and w eb
server.
The TLS/SSL protocol has undergone various revisions resulting in periodic version updates. Each new revision
w as designed to address the security w eaknesses discovered in the previous versions. Use of insecure protocol
versions w ill w eaken the strength of the transport protection and could allow an attacker to compromise, steal or
modify sensitive information. Correctly configuring the w eb 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 show n to be
susceptible to DROWN if it either:
 Allow s SSL 2.0 connections or
 Shares its private key w ith any other server that supports SSL 2.0
Simply supporting SSL 2.0 or sharing the server's private key w ith any another server that supports SSL 2.0 makes
the target server vulnerable to DROWN. The vulnerability allow s an attacker to decrypt any modern TLS connection
to eavesdrop and steal information exchanged betw een the clients and the target server. The attack is identified
by CVE-2016-0800.

Execution:
Each w eak protocol w as enumerated by establishing an SSL connection w ith 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 w eb application.
Implication:
SSL 2.0 may exhibit follow ing security w eaknesses:
 no protection against man-in-the-middle attacks
 same key used for authentication and encryption
 w eak 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 w ith sensitive data.
Fix:
1. Disable support for w eak protocols on the server.
 For Apache, modify the follow ing lines in httpd.conf or ssl.conf:
o SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1
o 187498
o 245030
o Security Guidance for IIS
2. Check SSL configurations on all servers that interact w ith 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 w ith any other server.

The follow ing protocols supported by the server should provide adequate protection:
Reference Info:
OWASP:
https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf
Microsoft:
Apache:
The DROWN Attack
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 betw een a client and w eb server. The TLS/SSL protocol has undergone various revisions resulting in
periodic version updates. Each new revision w as designed to address the security w eaknesses 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, w hich is prone bias attacks or uses Cipher Block Chaining (CBC) mode cipher, w hich enables
condition for POODLE (Padding Oracle On Dow ngraded Legacy Encryption) attacks.
Use of insecure protocol versions w ill w eaken the strength of the transport protection and could allow an attacker
to compromise, steal or modify sensitive information. Correctly configuring the w eb server to use the most secure
protocol is highly recommended.
Execution:

The list of supported SSL/TLS protocols can be obtained by running the server analyzer tool from HP security
toolkit supplied w ith HP WebInspect against the target server.
Implication:
Weak TLS/SSL protocols may exhibit any or all of the follow ing 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 w ith sensitive data.
Fix:
Disable support for the SSL 3.0 protocol on the server. Instead, TLSv1.1 and above should be used.
 For Apache, modify the follow ing lines in the server configuration:
o SSLProtocol ALL –SSLv2 -SSLv3 -TLSv1
 For Nginx, modify the follow ing lines in server configuration:
o ssl_protocols TLSv1.1 TLSv1.2;
o https://technet.microsoft.com/library/security/3009008
 For other servers, please refer to vendor specific documentation:
Reference Info:
OWASP:
https://www.pcisecuritystandards.org/pdfs/pcissc_assessors_nl_2008-11.pdf
Microsoft:

Apache:
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
The Transport Layer Security (TLS) protocol provides a protection mechanism to better protect authenticity,
confidentiality and integrity of the data transmitted betw een a client and a w eb server. The TLS protocol has
undergone various revisions resulting in periodic version updates. Each revision tries to address security w eakness
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, w henever possible.
TLS 1.0 is considered insecure as it lacks support for strong ciphersuites and is know n to be plagued by several
know n vulnerabilities. It either uses RC4 cipher, w hich is prone to bias attacks or uses Cipher Block Chaining
(CBC) mode cipher, w hich enables condition for POODLE (Padding Oracle On Dow ngraded 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 w ith 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 w ill w eaken the strength of the transport protection and could allow an attacker
to compromise, steal or modify sensitive information. Configuring the w eb server to use the most secure protocol,
TLS 1.1 or TLS 1.2 is highly recommended.

Implication:
Use of a w eakprotocol such as TLS 1.0 leaves the connection vulnerable to man-in-the-middle attacks. This w ould
allow the attacker to read and modify data on a secure TLS connection, thus compromising user security and
privacy. Its use w ould also limit the use of strong cipher suites that help protect data integrity and confidentiality.
Fix:
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 follow ing lines in the server configuration
o SSLProtocol ALL –SSLv2 -SSLv3 -TLSv1
 For Nginx, modify the follow ing lines in server configuration:
o ssl_protocols TLSv1.1 TLSv1.2;
o https://technet.microsoft.com/library/security/3009008
Reference Info:
OWASP:
NIST:
NIST SP 800-52 Revision 1
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:

Apache:
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 Cipher
Logjam is an attack against the Diffie-Hellman key exchange protocol used in TLS. Diffie-Hellman is a key
exchange protocol used w ithin 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 allow s the attacker to dow ngrade 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 follow ing
DHE_EXPORT ciphers:
Execution:
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:
A dow ngraded TLS connection allow s the Logjam attacker to easily read and modify any data passed over that
TLS connection.
Fix:
 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 follow ing know ledge 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)

Pantallas escaneo Sitio Web

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Pantallas escaneo Sitio Web

Ähnlich wie Pantallas escaneo Sitio Web (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Pantallas escaneo Sitio Web