You are on page 1of 1

client-supplied data gets

echoed back to the screen


reflected XSS problem

most common via search box

JS payload doesn't need to be


unique form of XSS
sent or echoed by web server

can be persistent if
similar to reflected XSS
incorporates cookies
3 types

DOM based XSS object structure to access &


DOM (Document Object Model) manipulate nodes, values and
attributes

completely relies on JS and insecure use of


input validation vulnerability
dynamically obtained data from DOM
on the client side JS
structure

stored XSS

user is able to define


content which gets
evaluated as javascript or
create own javascript
resulting from missing/bad blocks
input/input handling
Password Change/Forgotten Functions
developer doesn't apply needed
sanitzation for given context of user
Brute Forcible Login supplied input
XSS

Verbose Failure Messages technique to force web sites to display browser doesn't have to be
malicious code which gets executed in users susceptible to any
web browser vulnerability
Insecure Credential Distribution

user supplied data doesn't only all headers may be spoofed by logging infrastructure must the target is usually the admin,
Predictable Usernames/Initial Passwords
Logical Flaws reach the server via GET and user including cookie, referer and implement proper escaping for which will gain the attacker admin
POST host everything logged rights
Predictable Account Activation
Link/ID
variable width encoding can
make escaping invalid
Bad Passwords
encoding can pose a problem
server can't correctly check and filter the
Fail-Open Login encoding the browser uses to interpret the
page is a different

defective multi-stage login


history stealing getComputedStyle API visited style

if want access to a subdomain both pages intranet hacking


problem must explicitly set the document.domain to
the same value
JS can completely alter look of
web site
flash has xml policy files that possible attack methods defacement
define exceptions called
only the exact same domain can be leveraged for phishers
/crossdomain.xml
explicit exceptions can be made enforced by utilizing domain names to occur on the real website
can be accessed

new Header called Access-Control


only allow to read data abuse users browser to run as filesharing node
originating from the same Same Origin Policy applications without user
in xml XMLHttpRequest source approval
as part of anonymity network
<?access-control processing
instruction
unaware developer might those can be revealed by
compiled bytecode
include secrets into code decompilers and reversing
protocol
Client Side Flash Security each exact domain gets an crossdomain.xml for cross
sources are the same if the
hostname cross domain requests
following matches own sandbox sandbox communication

port (not for IE?) sandboxing

Java Security
session management
closely related to
authentication mechanism session management needed to browser connects to malicious
identify different users across server with dns timeout of 1
requests second
webapplications becoming like
desktop applications -> need http is stateless
state JS tells browser to connect
back in 2 seconds

main technology Cookies attack without dns pinning


browser resolves name again
since no longer valid
basic

dns server replies with arbitrary ip this ip may be in the intranet


digest address it wants to get the contents providing attacker access to the
from inner network
NTLM http authentication
technologies the browser pins once received IPs browser protection to prevent attackers from
(Kerberos) to domains to prevent the attack breaking the same-origin policy through DNS
above tricks

client certificates
the browser is re-requesting dns if
the web server isn't reachable
in cookie anymore
encoded session state
being pushed to client
in hidden form fields same as above, but this time the base
DNS Pinning Vulnerabilites it needs to firewall the port in question not the
attacker system firewalls itself to be
attack whole server, so the whole process can be
simple attack huge impact on unreachable for the browser in the second
carried out for different IPs on a single server
web app security request
anti-dns pinning

possible because browser implicitly appends checking the host header if the this would already happen if virtual
perform actions in users targeted system by the browser is hosting is used, but there usually is a
Cookies to every request for the allowed
behalf via users browser really ours default
domain(s)
anti-anti-dns pinning

cannot read from other exploits in client side request building


domain, but influence it
doesn't obey to same-origin policy Web Application Security anti-anti-anti-dns pinning mechanisms to spoof the host header defeats
CSRF this kind of protection

XSS and CSRF can let unsuspecting


user attack a webserver on attackers it is not possible to hijack session via
behalf automated sending of cookies with this,
because cookie sending is determined by
domain not IP
nonce could be read by JS
incorporate nonces into state-changing possibility to take over
XSS vulnerability would bypasses this counter measures
JS enables to act with web requests systems in the intranet
site like the user intranet scanning can be combined with an
automated search for vulnerabilities in the
intranet use XSS or CSRF exploit to attack users
webapp accepts provided browser to steal information or authentication
tokens as new sessions tokens
Session Hijacking

webapp doesn't create new redefine Array object to have


token on login Session Fixation the results accessible
request json from other side
via
attacker can smuggle new session token into <script> include XMLHttpRequest wouldn't
users browser and continue his session after work because of same origin
login policy
JavaScript Hijacking
guessable meaningful tokens user is authenticated on other
Sessions web service via cookie

reproducible algorithm
concealed sequences if web service discloses
enabling brute-forcing
privacy relevant information
attacks over json
the keyspace can be minimized the
better the timeframe of generation is token-generation process predictable tokens weak Session IDs
time dependency
known depends only/mostly on time
SQL databases are usually called indirected by a web
application, which passes a complete query containing
weak (P)RNG parts of user supplied content to the database
subsystem
tokens holds authorization data user doesn't need to log in static tokens
requests to retrieve
information
fallback to http after login
SELECT
injection point usually the
usage of https only cookies http for all static content
WHERE clause
disclosure of tokens on network
tricked by attacker to make http request to
creates new row
server, not matter if successful, token will
be disclosed
INSERT attackers usually have to guess database brute-forcing the number with
schema and therefore doesn't know the 1s (or 2000s for possible
logout doesn't invalidate session order and number of columns dates) or NULLs

user didn't log out vulnerable session termination


change one or more data rows
no session expiration
possibly user got force quit UPDATE
usual entry point the WHERE
clause and or the SET clause
so in default the cookie is sent in all cookies are default sent in every request
requests to subdomains and the domain web-servers sharing the same right-hand-side
removes one or more rows
itself of the domain
DELETE
domain
usual entry point is WHERE clause
enabling also other webservers on a
domain value can be changed
subdomain to read the cookie from liberal cookie scope
upto one below the tld
users combine two or more
SQL Injection SELECTs

too liberal path value again might enable similar to domain path defines to which
other users on the system to obtain cookies subdirectories on the server cookies will be path attacks can be leveraged to gain information
from users of that application passed from different tables than original
query

if an attacker uses the session of a user it will be


detected because the page token replied will not be selected fields must be same
the last provided, because there are two open UNION operator number and type (structure)
instances
pro Attacks
Server Side names of tables and fields
names can be queried from
can be leveraged to track user creating additional page tokens database specific metadata
must be known
movement on page tables
counter measures
opening several tabs at the same inject ORDER BY $colnum until search for columns of string type by
time will be interpreted as an con usual steps error to check for number of inserting NULL in all but one field, which
attack columns holds a string until string is displayed

deauthenticating user when suspicious Blind SQL injection


activity is noticed like modified hidden form reactive session termination
fields or strings associated with SQLi or XSS
timing attacks

correctly escaped user user content is fetched from database


content is written to the and used again without further
database sanitization
Second Order SQL Injection
foo' is fetched from database and used
foo' gets correctly escaped to
to create update statement for
foo'' as username
password without futher sanitization

Remote File Inclusion

executed code is built at


runtime containing user
supplied content
usually interpreted languages
utilizing special characters to break out of
Remote Code Execution data context therefore being able to
execute arbitrary commands

in compiled languages attack not leverages


syntactic features of programming payload contains machine code
language

Path Traversal

Web Application Firewall ModSecurity (Apache)

You might also like