Pantallas escaneo Sitio Web

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

http://www.securityfocus.com/infocus/1768%20

http://httpd.apache.org/info/css-security/apache_specific.html

http://www.cert.org/advisories/CA-2000-02.html

https://msdn.microsoft.com/en-us/security/aa973814.aspx

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

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

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.


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.


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



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.


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.


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.


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


o 187498

o 245030

o Security Guidance for IIS


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:



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 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.


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.


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.


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;


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 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.


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.


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;


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 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:


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.


A downgraded TLS connection allows the Logjam attacker to easily read and modify any data passed over that

TLS connection.


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)

Pantallas escaneo Sitio Web

Technology

Transcript of Pantallas escaneo Sitio Web