You are on page 1of 13

Core problems

www.ituniversity.ro
Testing web applications for vulnerabilities

Gabriel Avramescu
CEH, CCNA, CCAI, OSCP, ISO 27001
gabriel.avramescu@ituniversity.ro
1
Content
• Core problems
• Old, New
• Causes, Defenses
• User Input, User Access

www.ituniversity.ro
2
Old

www.ituniversity.ro
3
New

www.ituniversity.ro
4
New

www.ituniversity.ro
5
Problems?

www.ituniversity.ro
6
Core Problem
• Users can interfere with any piece of data transmitted
between the client and the server
• Users can send requests in any sequence and can submit
parameters at a different stage than the application expects
• Users are not restricted to using only a web browser to access

www.ituniversity.ro
the application.

7
Causes?
• Security awareness
• The users and programmers are not aware of the threats
• Custom development
• Secure frameworks are (insecure) modified to comply with

www.ituniversity.ro
customer’s requirements
• Simple code ≠ secure code
• Resource constraints
• Time, money (good programmers), paid (and secure) frameworks,
etc.
• Complexity (web2.0, cloud)
• Evolving threats
8
Defenses

• User access
• User input
• Handling Attackers

www.ituniversity.ro
• Logging

9
User Access
• Handling user access to the application’s data and functionality to
prevent users from gaining unauthorized access
• Authentication
• Two-factor authentication, brute-forcible prone
• Session management

www.ituniversity.ro
• After successfully logging in to the application, the user accesses
various pages and functions, making a series of HTTP requests from
his browser. At the same time, the application receives countless
other requests from different users, some of whom are
authenticated and some of whom are anonymous. To enforce
effective access control, the application needs a way to identify and
process the series of requests that originate from each unique user.
• Access control
• Ex.: if you are logged in as user X, don’t access user’s Y data 10
User Input
• Handling user input to the application’s functions to prevent malformed
input from causing undesirable behavior
• Known bad (blacklisting)
• Do not permit certain characters in website’s form (such as < > ‘ used to
modify the webpage or to change it’s content)
• Known good (whitelisting)
• Permit only certain characters (Ex. For a form designated for phone number,

www.ituniversity.ro
do not allow letters)
• Sanitization
• Remove what was it should not be there (remove letters from a phone
number’s designated form)
• Boundary validation
• Ex.: the phone number should not be longer than 10 digits
• <script>
• <scr<script>ipt>
• %27
• %2527 11
• https://www.owasp.org/index.php/Data_Validation
Handling Attackers
• Handling attackers to ensure that the application behaves
appropriately when being directly targeted, taking suitable
defensive and offensive measures to frustrate the attacker
• Handling errors
• Use a generic error page, do not reveal error to the user, they can

www.ituniversity.ro
be later used to develop further attacks
• Maintaining audit logs
• Alerting administrators
• Reacting to attacks
• Ex.: ban/block the user, the IP, etc.

12
Logging

• Authentication events
• Key transactions
• Login, logout, failed logins, important changes (ex. Money

www.ituniversity.ro
transactions)
• Bad behavior
• Access attempts that are blocked by the access control
mechanisms
• Known attacks
• Ex.: If a user try to insert the single quote character ‘ , it may try a
SQL injection attac
13

You might also like