ATAQUES-PRESENTACION

1-INJECTIONInyección SQL es un método de infiltración de código intruso que se vale de unavulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas para realizar operaciones sobre una base de datos.

El origen de la vulnerabilidad radica en el incorrecto chequeo o filtrado de las variables utilizadas en un programa que contiene, o bien genera, código SQL. Es, de hecho, un error de una clase más general de vulnerabilidades que puede ocurrir en cualquier lenguaje de programación o script que esté embebido dentro de otro.

Se conoce como Inyección SQL, indistintamente, al tipo de vulnerabilidad, al método de infiltración, al hecho de incrustar código SQL intruso y a la porción de código incrustado.

2-Cross-site Scripting (XSS) Attack How Cross-site Scripting works

Cross-site Scripting (XSS) refers to client-side code injection attack wherein

an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially

While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

In order to run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject a payload into a web page that the victim visits. Of course, an attacker could use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload.

In order for an XSS attack to take place the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string that will be used within the web page and treated as code by the victim’s browser.

The following server-side pseudo-code is used to display the most recent comment on a web page.

3-BROKEN AUTHENTICATION AND SESSION MANAGEMENT

Authentication and session management includes all aspects of handling user authentication and managing active sessions. Authentication is a critical aspect of this process, but even solid authentication mechanisms can be undermined by flawed credential management functions, including password change, forgot my password, remember my password, account update, and other related functions. Because “walk by” attacks are likely for many web applications, all account management functions should require reauthentication even if the user has a valid session id.

User authentication on the web typically involves the use of a userid and password. Stronger methods of authentication are commercially available such as software and hardware based cryptographic tokens or biometrics, but such mechanisms are cost prohibitive for most web applications. A wide array of account and session management flaws can result in the compromise of user or system administration accounts. Development teams frequently underestimate the complexity of designing an authentication and session management scheme that adequately protects credentials in all aspects of the site. Web applications must establish sessions to keep track of the stream of requests from each user. HTTP does not provide this capability, so web applications must create it themselves. Frequently, the web application environment provides a session capability, but many developers prefer to create their own session tokens. In either case, if the session tokens are not properly protected, an attacker can hijack an active session and assume the identity of a user. Creating a scheme to create strong session tokens and protect them throughout their lifecycle has proven elusive for many developers. Unless all authentication credentials and session identifiers are protected with SSL at all times and protected against disclosure from other flaws, such as cross site scripting, an attacker can hijack a user’s session and assume their identity.

4-INSECURE DIRECT OBJECT REFERENCES

Top 10 2013-A4-Insecure Direct Object References

← A3-Cross-Site Scripting (XSS)

2013 Table of Contents

2013 Top 10 ListA5-Security Misconfiguration →

Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts

Application Specific ExploitabilityEASY

PrevalenceCOMMON

DetectabilityEASY

ImpactMODERATE

Application / Business Specific

Consider the types of users of your system. Do any users have only partial access to certain types of system data?

Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted?

Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.

Such flaws can compromise all the data that can be referenced by the parameter. Unless object references are unpredictable, it’s easy for an attacker to access all available data of that type.

Consider the business value of the exposed data.

Also consider the business impact of public exposure of the vulnerability

Am I Vulnerable To 'Insecure Direct Object References'?The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:

1. For direct references to restricted resources, does the application fail to verify the user is authorized to access the exact resource they have requested?

2. If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?

How Do I Prevent 'Insecure Direct Object References'?Preventing insecure direct object references requires selecting an approach for protecting each user

accessible object (e.g., object number, filename):

1. Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized

resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized

for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to

Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.

map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both

sequential and random access reference maps that developers can use to eliminate direct object references.

2. Check access. Each use of a direct object reference from an untrusted source must include an access control check

3. to ensure the user is authorized for the requested object.

Example Attack ScenariosThe application uses unverified data in a SQL call that is accessing account information:

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connection.prepareStatement(query , … );

pstmt.setString( 1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account.

http://example.com/app/accountInfo?acct=notmyacct

ReferencesOWASP

OWASP Top 10-2007 on Insecure Dir Object References

ESAPI Access Reference Map API

ESAPI Access Control API (See isAuthorizedForData(), isAuthorizedForFile(),

isAuthorized

ForFunction() )

For additional access control requirements, see the ASVS requirements area for Access Control (V4).

External

CWE Entry 639 on Insecure Direct Object References

CWE Entry 22 on Path Traversal (is an example of a Direct Object Reference

attack)

5-CROSS SITE REQUEST FORGERY

El CSRF (del inglés Cross-site request forgery o falsificación de petición en sitios cruzados) es un tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía.

Un ataque CSRF fuerza al navegador web validado de una víctima a enviar una petición a una aplicación web vulnerable, la cual entonces realiza la acción elegida a través de la víctima. Al contrario que en los ataques XSS, los cuales explotan la confianza que unusuario tiene en un sitio en particular, el cross site request forgery explota la confianza que un sitio tiene en un usuario en particular .

6-SECURITY MISSCONFIGURATION

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

Top 10 2013-A5-Security Misconfiguration

← A4-Insecure Direct Object References

2013 Table of Contents

2013 Top 10 ListA6-Sensitive Data Exposure →

Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts

Application Specific ExploitabilityEASY

PrevalenceCOMMON

DetectabilityEASY

ImpactMODERATE

Application / Business Specific

Consider anonymous external attackers as well as users with their own accounts that may attempt to compromise the system. Also consider insiders wanting to disguise their actions.

Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system.

Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

The system could be completely compromised without you knowing it. All of your data could be stolen or modified slowly over time.

Recovery costs could be expensive

The system could be completely compromised without you knowing it. All your data could be stolen or modified slowly over time.

Recovery costs could be expensive.

Am I Vulnerable To 'Security Misconfiguration'?Is your application missing the proper security hardening across any part of the application stack? Including:

How Do I Prevent 'Security Misconfiguration'?The primary recommendations are to establish all of the following:

1. Is any of your software out of date? This includes the OS, Web/App

Server, DBMS, applications, and all code libraries (see new A9).

2. Are any unnecessary features enabled or installed (e.g., ports, services,

pages, accounts, privileges)?

3. Are default accounts and their passwords still enabled and unchanged?

4. Does your error handling reveal stack traces or other overly informative

error messages to users?

5. Are the security settings in your development frameworks (e.g., Struts,

Spring, ASP.NET) and libraries not set to secure values?

Without a concerted, repeatable application security configuration process, systems are at a higher risk.

1. A repeatable hardening process that makes it fast and easy to deploy another

environment that is properly locked down. Development, QA, and production

environments should all be configured identically (with different passwords

used in each environment). This process should be automated to minimize the

effort required to setup a new secure environment.

2. A process for keeping abreast of and deploying all new software updates and

patches in a timely manner to each deployed environment. This needs to

include all code libraries as well (see new A9).

3. A strong application architecture that provides effective, secure separation

between components.

4. Consider running scans and doing audits periodically to help detect future

misconfigurations or missing patches.

Example Attack ScenariosScenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.

Scenario #2: Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she decompiles and reverse engineers to get all your custom code. She then finds a serious access control flaw in your application.

Scenario #3: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.

Scenario #4: App server comes with sample applications that are not removed from your production server. Said sample applications have well known security flaws attackers can use to compromise your server.

ReferencesOWASP

OWASP Development Guide: Chapter on Configuration

OWASP Code Review Guide: Chapter on Error Handling

OWASP Testing Guide: Configuration Management

OWASP Testing Guide: Testing for Error Codes

OWASP Top 10 2004 - Insecure Configuration Management

For additional requirements in this area, see the ASVS requirements area for Security Configuration (V12).

External

PC Magazine Article on Web Server Hardening

CWE Entry 2 on Environmental Security Flaws

CIS Security Configuration Guides/Benchmarks

7-INSECURE CRIPTOGRAPHICS STORAGE

Insecure Cryptographic Storage is a common vulnerability that occurs when sensitive data is not stored securely. Insecure Cryptographic Storage isn’t a single vulnerability, but a collection of vulnerabilities. The vulnerabilities in the collection all have to do with making sure your most important data is encrypted when it needs to be. This includes:

Making sure you are encrypting the correct data Making sure you have proper key storage and management Making sure that you are not using known bad algorithms Making sure you are not implementing your own cryptography, which may or may not be secureDevelopers often assume that data storage will not be examined by an arbitrary user. But many users of an application or program have access to the registry, temporary files and databases. It’s possible for these users to access sensitive data in its unencrypted format using temporary, hidden and registry files. It is also possible for an attacker to gain access using another one of the OWASP Top 10 vulnerabilities, such as Direct Object Access.

Developers should identify all sensitive data and encrypt that data, even when it’s stored on a hard drive. Ensure that sensitive data cannot be easily overwritten and overwrite sensitive memory locations immediately. Additionally, identify the people who should and shouldn’t have knowledge of secrets such as proprietary algorithms, encryption keys and DRM. In most cases, it’s recommended to hide these secrets from even the administrator. Additionally, identify all sensitive data read into the memory and overwrite it with random data.

To ensure secure storage of sensitive data, follow these steps:

Identify all sensitive data and encrypt it even when it’s stored on a hard drive Ensure that sensitive data cannot be overwritten Overwrite sensitive memory locations immediately after the data is no longer needed in memory Identify people who should and shouldn’t know secrets Keep secrets such as proprietary algorithms, encryption keys and DRM even from the administrator Identify sensitive data read into memory, overwrite it with random data and use strong encryption to safeguard itHow to Detect and Secure Insecure Cryptography Storage IssuesThe ways to detect and fix cryptographic storage issues fall into two camps.

1. On one side, you have flaws such as improper key management or not encrypting the correct data. The way to fix these is to sit down and look at what the scope of your application is, look at internal business processes and review ways to make sure that you are following best practice.

2. On the other hand, issues like implementing your own insecure cryptography or using known insecure algorithms can be fixed by using a whole variety of security scanning tools.

8-FAILURE TO RESTRICT URL ACCESS

Frequently, the only protection for a URL is that links to that page are not presented to unauthorized users. However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages, invoke functions, and view data. Security by obscurity is not sufficient to protect

sensitive functions and data in an application. Access control checks must be performed before a request to a sensitive function is granted, which ensures that the user is authorized to access that function. ENVIRONMENTS AFFECTED All web application frameworks are vulnerable to failure to restrict URL access. VULNERABILITY The primary attack method for this vulnerability is called "forced browsing", which encompasses guessing links and brute force techniques to find unprotected pages. Applications frequently allow access control code to evolve and spread throughout a codebase, resulting in a complex model that is difficult to understand for developers and security specialists alike. This complexity makes it likely that errors will occur and pages will be missed, leaving them exposed. Some common examples of these flaws include: "Hidden" or "special" URLs, rendered only to administrators or privileged users in the presentation layer, but accessible to all users if they know it exists, such as /admin/adduser.php or /approveTransfer.do. This is particularly prevalent with menu code. Applications often allow access to "hidden" files, such as static XML or system generated reports, trusting security through obscurity to hide them. Code that enforces an access control policy but is out of date or insufficient. For example, imagine /approveTransfer.do was once available to all users, but since SOX controls were brought in, it is only supposed to be available to approvers. A fix might have been to not present it to unauthorized users, but no access control is actually enforced when requesting that page. Code that evaluates privileges on the client but not on the server, as in this attack on MacWorld 2007, which approved "Platinum" passes worth $1700 via JavaScript on the browser rather than on the server.

9-INSUFICCIENT TRANSPORT LAYER PROTECTION

Top 10 2010-A9-Insufficient Transport Layer ProtectionCon frecuencia las aplicaciones no protegen el .

tráfico de red . Pueden utilizar SSL / TLS durante la autenticación , pero no en otra parte , los datos que exponen y los identificadores de sesión a la interceptación . Los certificados caducados o mal configurados también se pueden usar .

Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts

Application SpecificExploitability

DIFFICULTPrevalenceCOMMON

DetectabilityEASY

ImpactMODERATE

Application / Business Specific

Consider anyone who can monitor the network traffic of your users. If the application is on the internet, who knows how your users access it. Don’t forget back end connections.

Monitoring users’ network traffic can be difficult, but is sometimes easy. The primary difficulty lies in monitoring the proper network’s traffic while users are accessing the vulnerable site.

Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used.

Detecting basic flaws is easy. Just observe the site’s network traffic. More subtle flaws require inspecting the design of the application and the server configuration.

Such flaws expose individual users’ data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.

Consider the business value of the data exposed on the communications channel in terms of its confidentiality and integrity needs, and the need to authenticate both participants.

Am I Vulnerable To 'Insufficient Transport Layer Protection'?

The best way to find out if an application has sufficient transport layer protection is to verify that:

1. SSL is used to protect all authentication related traffic.

2. SSL is used for all resources on all private pages and services. This protects all

data and session tokens that are exchanged. Mixed SSL on a page should be

avoided since it causes user warnings in the browser, and may expose the

user’s session ID.

3. Only strong algorithms are supported.

How Do I Prevent 'Insufficient Transport Layer Protection'?

Providing proper transport layer protection can affect the site design. It’s easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private pages. Others use SSL only on ‘critical’ pages, but this can expose session IDs and other sensitive data. At a minimum, do all of the following:

1. Require SSL for all sensitive pages. Non-SSL requests to these pages

should be redirected to the SSL page.

2. Set the ‘secure’ flag on all sensitive cookies.

3. Configure your SSL provider to only support strong (e.g., FIPS 140-2

4. All session cookies have their ‘secure’ flag set so the browser never transmits

them in the clear.

5. The server certificate is legitimate and properly configured for that server. This

includes being issued by an authorized issuer, not expired, has not been

revoked, and it matches all domains the site uses.

compliant) algorithms.

4. Ensure your certificate is valid, not expired, not revoked, and matches

all domains used by the site.

5. Backend and other connections should also use SSL or other encryption

technologies.

Example Attack Scenarios

Scenario #1: A site simply doesn’t use SSL for all pages that require authentication. Attacker simply monitors network traffic (like an open wireless or their neighborhood cable modem network), and observes an authenticated victim’s session cookie. Attacker then replays this cookie and takes over the user’s session.

Scenario #2: A site has improperly configured SSL certificate which causes browser warnings for its users. Users have to accept such warnings and continue, in order to use the site. This causes users to get accustomed to such warnings. Phishing attack against the site’s customers lures them to a lookalike site which doesn’t have a valid certificate, which generates similar browser warnings. Since victims are accustomed to such warnings, they proceed on and use the phishing site, giving away passwords or other private data.

Scenario #3: A site simply uses standard ODBC/JDBC for the database connection, not realizing all traffic is in the clear.

References

OWASP

For a more complete set of requirements and problems to avoid in this area, see theASVS requirements on Communications Security (V10).

OWASP Transport Layer Protection Cheat Sheet

OWASP Top 10-2007 on Insecure Communications

OWASP Development Guide: Chapter on Cryptography

OWASP Testing Guide: Chapter on SSL/TLS Testing

External

CWE Entry 319 on Cleartext Transmission of Sensitive Information

SSL Labs Server Test

Definition of FIPS 140-2 Cryptographic Standard

10-INVALIDATED REDIRECTS AND FORWARDS

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing (Phishing o suplantación de identidad es un término informático que denomina un modelo de abuso informático y que se

comete mediante el uso de un tipo de ingeniería social, caracterizado por intentar adquirir información confidencial de forma fraudulenta (como puede ser una contraseña o información detallada)  scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.

Safe URL RedirectsWhen we want to redirect a user automatically to another page (without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:

Java

response.sendRedirect("http://www.mysite.com");

PHP

<?php /* Redirect browser */ header("Location: http://www.mysite.com/"); ?>