Web and Mobile Application Security

Web and Mobile
Application
Security
-Project Report
1

Times are Changing
• Hacking methods changes with evolution in technologies. The Web as the medium of choice for
communication means hackers focus their efforts there.
• Network firewalls, which were once constructed to block dangerous protocols, particularly remote
procedure calls (which enable programs to communicate), now find themselves helpless as these
same protocols reemerge, encapsulated inside HTTP.
• This opens up new avenues to explore and exploit. HTTP, once merely used for text, is now a generic
protocol that can transfer anything – of course text and images, but also complicated transactions,
containing sensitive data such as credit cards or other financial and personal information.
Recent studies indicate over 70% of all web a contain critical security flaws. Given the financial and
time costs, loss of reputation and potential flight of customers that any compromised company may
incur, this is an amazingly high number. With estimated worldwide cyber crime losses in 2011 over
$388 billion, corporations, both large and small, are focusing considerable attention towards the
security of their physical infrastructures as well as their outward facing web applications
2

What Are Application Security Risks?
Attackers can potentially use many different paths through your application to do harm to your business. Each
of these paths represents a risk that may or may not be serious enough to warrant attention.
• Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult.
• Similarly, the harm that is caused may range from nothing all the way through putting you out of business.
• To determine the risk to your organization, you can evaluate the likelihood associated with the threat agent,
attack vector, and security weakness and combine it with an estimate of the technical and business impact to
your organization.
• Together, these factors determine the overall risk
4

OWASP TOP 10 Web Vulnerabilities
Open Web Application Security Project is an open project aiming at identifying and preventing causes for
unsecure software. OWASP identified the top ten most experienced vulnerabilities in web application.
1. Injection
Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a
command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or
accessing unauthorized data.
2. Broken Authentication and Session Management
Application functions related to authentication and session management are often not implemented correctly,
allowing attackers to compromise passwords, keys, session tokens, or exploit implementation flaws to assume other
users’ identities
3. Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper
validation and escaping. XSS allows attackers to execute script in the victim’s browser which can hijack user
sessions, deface web sites, or redirect the user to malicious sites.
5

4. Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as
a file, directory, or database key. Without an access control check or other protection, attackers can manipulate
these references to access unauthorized data
6. Sensitive Data Exposure
Many web applications do not properly protect sensitive user data such as credit cards information/Bank account
info/authentication credentials. Hackers might end up stealing those weakly protected data to conduct credit card
fraud, identity theft, or other crimes
7. Missing Function Level Access Control
Most of the web applications verify function level access rights before making that functionality accessible to the
user, However, if the same access control checks are NOT performed on the server, hackers will be able to penetrate
into the application without proper authorization.
5. Security Misconfiguration
Security Misconfiguration arises when Security settings are defined, implemented, and maintained as defaults. Good
security requires a secure configuration defined and deployed for the application, web server, database server, and
platform.
6

10. Invalidated Redirects and Forwards
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to
determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware
sites, or use forwards to access unauthorized pages.
9. Using Components with unknown vulnerabilities
This kind of threat occurs when the Components such as libraries, frameworks used within the app almost always
executes with full privileges. If a vulnerable component is exploited it makes hackers job easier to cause a serious
data loss or server takeover.
8. Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session
cookie and any other authentication information, to a vulnerable web application. This allows the attacker to force
the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
7

Injection
SQL injection is a code injection technique, used to attack data-driven applications, in which
nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to
the attacker).
Business Impact
• Data stealing/modification/deletion
• Reputation under stake
Technical Impacts
• Result in data loss or corruption
• Can lead to host takeover
• Lack of accountability, denial of access
Security Weakness
• Very prevalent
• Often found in Sql, Xpath, LDAP queries
• Found in program arguments
Attack Vectors
• Attacker sends simple text-based attacks that exploit the syntax of the
targeted interpreter.
Threat Agents
• Untrusted data to the system, including external users, internal users, and
administrators
8

SQL Injection Example
Let’s look at the example code below.
Since under all circumstances, one will be equal to one, the query will return all records in the
database. In this way, an unauthorized user will be able to view sensitive information.
String SQLQuery = “SELECT Username, Password
FROM users WHERE ID= ‘ ” + Password + “ ‘ ”;
Statement stmt= connection.createStatement();
ResultSet rs= stmt.executeQuery(SQLQuery);
While (rs.next()) {…}
SQL Injection
ID: prateek123
Password: password
Select * from Users where ID= ‘prateek123’
and password =‘ password‘
ID: ‘OR 1=1’ #
Password: */--
9

Broken Authentication and Session Management
When authentication functions related to the application are NOT implemented correctly which will allow
hackers to compromise passwords or session ID's or to exploit other implementation flaws using other users
credentials
Business Impact
• Public exposure of the vulnerability
• Business value of the affected data or application functions
Technical Impacts
• May allow some even all accounts to be compromised
• Only successful, the attacker can o anything
Security Weakness
• Developers build custom authentication and session management
schemes, but building correctly is hard
Attack Vectors
• Uses leaks or flaws in the authentication or session management.
Threat Agents
• Anonymous external attacker, as well as users with their own accounts who
may attempt to steal accounts from others
10

Example
An e-commerce application supports URL rewriting, putting session IDs in the URL:
http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop
An authenticated user of the site forwards the URL to their friends to know about the discounted
sales. He e-mails the above link without knowing that the user is also giving away the session ID's.
When his friends use the link they will use his session and credit card.
Victim Browser Unauthenticated Site
Post/Login
Cookies: Auth/Token
11

Cross Site Scripting
Cross Site Scripting(XSS) happens whenever an application takes untrusted data and sends it to the
client(browser) without validation. This allows attackers to execute malicious scripts in the victim's browser.
Business Impact
• Affects the data
• Reputation under stake
Technical Impacts
• Script Execution on victim browser by attacker
Security Weakness
• Very prevalent
• Happens is the data sent from browser is NOT validated properly
Attack Vectors
• Sends untrusted data/simple text based attacks.
• Exploits the syntax of the targeted interpreter
Threat Agents
• Untrusted data sent to the system by the internal/external users or admins
12

Example
Attacker
Victim
Vulnerable
web page Saves Malicious
script into database
Data Containing the
Malicious Script is loaded
Injects Malicious Script
Malicious Script may get
Executed call back to the attacker
User request data
From server
Attacker injects malicious script on the website which when opened by the victim is run on his
browser and there by attacker can form malicious operations on the victim’s browser through the
script
13

Insecure Direct Object References
A direct object reference is likely to occur when a developer exposes a reference to an internal
implementation object, such as a file, directory, or database key without any validation mechanism which will
allow attackers to manipulate these references to access unauthorized data
Business Impact
• Consider the business impact of public exposure od the vulnerability
Technical Impacts
• Can compromise all the data that can be referenced by the parameter
Security Weakness
• Applications don’t always verify the user is authorized for the target object.
This results in IDOT
Attack Vectors
• Attacker, an authorized system user, simply changes a parameter value that
directly refers to a system object
Threat Agents
• Any user who has only partial access to certain types of system data
14

Example
The App uses unverified data in a SQL call that is accessing account information.
String sqlquery = "SELECT * FROM useraccounts WHERE account = ?"; PreparedStatement st =
connection.prepareStatement(sqlquery , ? ); st.setString( 1, request.getParameter("acct")); ResultSet
results = st.executeQuery( );
The attacker modifies the query parameter in their browser to point to Admin:
http://webapp.com/app/accountInfo?acct=admin
In the above example attacker modifies the query parameter in their browser to point to the Admin
rights and now he can perform all the operations as an admin which can be dangerous for the
website and its users.
15

Security Misconfiguration
Security Misconfiguration arises when Security settings are defined, implemented, and maintained as
defaults. Good security requires a secure configuration defined and deployed for the application, web server,
database server, and platform.
Business Impact
• All of your data could be stolen or modified slowly over time.
• Recovery cost could be expensive
Technical Impacts
• All of your data could be stolen or modified slowly over time.
• Recovery cost could be expensive
Security Weakness
• can happen at any level including the platform, web server, application
server, database, and custom code.
Attack Vectors
• Attacker accesses default accounts, unused pages, unpatched flaws,
unprotected files and directories, etc.
Threat Agents
• Anonymous external attackers as well as users with their own accounts
that may attempt to compromise the system.
16

Example
Below are some of the classic examples of security misconfiguration :
• If Directory listing is not disabled on the server and if attacker discovers the same then the attacker can simply
list directories to find any file and execute it. It is also possible to get the actual code base which contains all
your custom code and then to find a serious flaws in the application.
• App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws.
Attackers grab those extra information that the error messages provides which is enough for them to penetrate.
• App servers usually comes with sample apps that are NOT well secured. If not removed from production server
would result in compromising your server.
framework
Hardened OS
Web Server
App server
Database
Attacker
17

Sensitive Data Exposure
Many web applications do not properly protect sensitive user data such as credit cards information/Bank
account info/authentication credentials. Hackers might end up stealing those weakly protected data to
conduct credit card fraud, identity theft, or other crimes.
Business Impact
• Legal liability if the data is exposed
• Damage to your reputation
Technical Impacts
• information includes sensitive data such as health records, credentials,
personal data, credit cards,
Security Weakness
• most common flaw is simply not encrypting sensitive data
Attack Vectors
• do man-in-the-middle attacks, or steal clear text data off the server
Threat Agents
• who can gain access to your sensitive data and any backups of that data
18

Example
Attacker
Spear Phishing
Email
Sensitive Data
Email-Filtering
(Anti-Virus/Spam)
Compromised
User
Sensitive Data
Proxy,IPS/IDS
The above example is the case when sensitive data of the user is exposed due to the
Network firewall issues or some physical data or any other backup that is not secured.
After which the attacker can use the data to perform the respective attacks like having credit card
Information of the victim his money can be stolen
19

Missing Function Level Access Control
Most of the web applications verify function level access rights before making that functionality accessible to
the user, However, if the same access control checks are NOT performed on the server, hackers will be able to
penetrate into the application without proper authorization.
Business Impact
• the impact to your reputation if this vulnerability became public
Technical Impacts
• allow attackers to access unauthorized functionality
• Administrative functions are key targets for this type of attack.
Security Weakness
• function level protection is managed via configuration, and the system is
misconfigured
• Proper code checks
Attack Vectors
• who is an authorized system user, simply changes the URL or a parameter
to a privileged function
Threat Agents
• Anyone with network access can send your application a request
20

Example
The hacker simply forces target URLs. Usually admin access requires authentication, however, if the
application access is NOT verified an unauthenticated user can access admin page
Below URL might be accessible to an authenticated user http://website.com/app/standarduserpage
A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page
Define access control
rules for a service
consumer
Claims checked in app
21

Cross-Site Request Forgery(CSRF)
A CSRF attack forces an authenticated user(victim) to send a forged HTTP request, including the victim's
session cookie to a vulnerable web application which allows the attacker to force the victim's browser to
generate request such that the vulnerable app perceives as legitimate requests from the victim.
Business Impact
• impact to your reputation
• Imagine not being sure if users intended to take these actions.
Technical Impacts
• Attackers can trick victims into performing any state changing operation
the victim is authorized to perform
Security Weakness
• Detection of CSRF flaws is fairly easy via penetration testing or code
analysis
Attack Vectors
• Attacker creates forged HTTP request and tricks a victim into submitting
them via images tags,XSS,etc
Threat Agents
• Anyone who can load content into users browser and thus force them to
submit a request to your website
22

Example
Bank.com
Hacker
<script> or<img>
Downloaded and executed in
browser
Victim browses a page with malicious
content
Email
Router
Request for money
Transfer
Change Router config
Forward Email
Victim
Since the user is authenticated to the website, than attacker can perform all those tasks that the victim can do
from the victim’s browser in case when the vulnerability is not secured.
23

Using Components with Known Vulnerabilities
This kind of threat occurs when the Components such as libraries, frameworks used within the app almost
always executes with full privileges. If a vulnerable component is exploited it makes hackers job easier to
cause a serious data loss or server takeover.
Business Impact
• It could be trivial or it could mean complete compromise.
Technical Impacts
• full range of weaknesses is possible, including injection, broken access
control, XSS, etc.
Security Weakness
• Virtually every application has these issues because developers don’t focus
on ensuring their components are up to date
Attack Vectors
• Attacker identifies a weak component through scanning or manual analysis
Threat Agents
• Libraries in a framework can be identified and exploited with automated
tools
24

Example
Below are the examples of Using Components with Known Vulnerabilities :
• Attackers could invoke any web service with full permission By failing to provide an identity
token.
• Remote-code execution with Expression Language injection vulnerability was introduced through
the Spring Framework for Java based apps.
Attacker targets to
software
vulnerability
Exploits may arrive via
- Attachment to email messages
- Compromised websites
- Social networking sites
25

Invalidated Redirects and Forwards
Most Web applications on net frequently redirect and forward users to other pages or other external
websites, however, without validating the credibility of those pages, hackers can redirect victims to phishing
or malware sites, or use forwards to access unauthorized pages
Business Impact
• What if they get owned by malware?
• What if attackers can access internal only functions
Technical Impacts
• Applications frequently redirect users to other pages, or use internal
forwards in a similar manner.
Security Weakness
• function level protection is managed via configuration, and the system is
misconfigured
• Proper code checks
Attack Vectors
• Attacker links to invalidated redirect and tricks victims into clicking it
Threat Agents
• anyone who can trick your users into submitting a request to your website
26

All web application used to forward users to different parts of the site. In order to achieve the same,
some pages use a parameter to indicate where the user should be redirected if an operation is
successful. The attacker crafts an URL that will pass the application's access control check and then
forwards the attacker to administrative functionality for which the attacker has not got the access.
http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp
Example
Let us say, the application has a page - redirect.jsp which takes a parameter redirect url. The hacker
add an malicious URL that redirects users which performs phishing/installs malware.
http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com
Opens Website
(www.fb.com?redirecturl=hacker.com)
Fb.com
Hacker.com
27

Preventing SQL Injection
• SQL injection can be prevented by adopting an input validation technique in which user input is
authenticated against a set of defined rules for length, type and syntax and also against business
rules.
• Users with the permission to access the database have the least privileges should be ensured.
Additionally, do not use system administrator accounts like “sa” for web applications. Also, you
should always make sure that a database user is created only for a specific application and this
user is not able to access other applications. Another method for preventing SQL injection attacks
is to remove all stored procedures that are not in use.
• Use strongly typed parameterized query APIs with placeholder substitution markers, even when
calling stored procedures.
• Show care when using stored procedures since they are generally safe from injection. However, be
careful as they can be injectable (such as via the use of exec() or concatenating arguments within
the stored procedure).
29

Broken Authentication and Session Management
• Develop a strong authentication and session management controls such that it meets all the
authentication and session management requirements defined in OWASP’s Application Security
Verification Standard
• Dev should ensure that they avoid XSS flaws that can be used to steal session IDs.
Cross Site Scripting
• Developers has to ensure that they escape all untrusted data based on the HTML context such as
body, attribute, JavaScript, CSS, or URL that the data will be placed into.
• For the application that needs special characters as input, there should be robust validation
mechanisms in place before accepting them as valid inputs.
30

Insecure Direct Object References
Dev can use the below resources/points as a guide to prevent insecure direct object reference during
development phase itself:
• Developers should Use only one user or session for indirect object references.
• It is also recommended to check the access before using a direct object reference from an
untrusted source.
• All environments such Development, QA, and production environments should all be configured
identically using different passwords used in each environment that cannot be hacked easily.
• Ensure that a strong application architecture is being adopted that provides effective, secure
separation between components
• It can also minimize the possibility of this attack by running automated scans and doing audits
periodically .
31

Sensitive Data Exposure
• It is NOT advised to store sensitive data unnecessarily and should be scraped as soon as possible if
not required.
• It is important to ensure that we incorporate strong and standard encryption algorithms are used
and proper key management is in place.
• It can also be avoided by Disabling autocomplete on forms that collect sensitive data such as
password and disable caching for pages that contain sensitive data.
Missing Function Level Access Control
• The authentication mechanism should deny all access by default, and provide access to specific
roles for every function
• In a workflow based application, verify the user state before allowing them to access any
resources.
32

Cross-Site Request Forgery(CSRF)
• CSRF can be avoided by creating an unique token in a hidden field which would be sent in the
body of the HTTP request rather than in an URL, which is more prone to exposure.
• Forcing the user to authenticate or proving that they are a user in order to protect CSRF (e.g. -
CAPTCHA).
• All environments such Development, QA, and production environments should all be configured
identically using different passwords used in each environment that cannot be hacked easily.
• Ensure that a strong application architecture is being adopted that provides effective, secure
separation between components
• It can also minimize the possibility of this attack by running automated scans and doing audits
periodically .
33

Using Components with Known Vulnerabilities
• Identify all components and the versions that are being used in the webapps not just restricted to
database/frameworks.
• Keeping all the components such as public databases, project mailing lists unto date.
• It is important to add security wrappers around components that are vulnerable in nature.
Invalidated Redirects and Forwards
• It is better to avoid using redirects and forwards.
• If unavoidable then it should be done without involving user parameters in redirecting the
destination.
34

Mobile Application Security
35

Mobile Application Security
Mobile app security refers to the enforcement of access and data protection measures for
individual apps. Examples of such app security policies include app-level VPN, data encryption,
corporate authentication, data wipe and copy/paste protection.
As evident from the information in the image, our apps know much more about us than we think
36

OWASP TOP 10 Mobile Security
The OWASP Top 10 Mobile Security Project is a centralized resource intended to give
developers and security teams the insights and resources they need to build and
maintain secure mobile applications.
• Weak Server Side controls1.
• Insecure Data Storage2.
• Insufficient Transport Layer Protection3.
• Unintended Data Leakage4.
• Poor Authorization and Authentication5.
• Broken Cryptography6.
• Client Side Injection7.
• Security Decisions Via Untrusted Inputs8.
• Improper Session Handling9.
• Lack of Binary Protections10.
37

Weak Server Side Controls
Weak Server Side Controls encompasses almost everything that a mobile application can do badly that does
not take place on the phone. Experience suggests that several factors have lead to a proliferation of server-
side vulnerabilities
Business Impact
• Adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the
mobile device
• May lead to information loss
Technical Impacts
• An adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the
mobile device.
Security Weakness
• The organization must expose a web service or API call that is consumed by
the mobile app
Attack Vectors
• The attack vectors correspond to the same attack vectors available through
the traditional OWASP Top Ten.
Threat Agents
• Include any entity that acts as a source of untrustworthy input to a
backend API service, web service.
38

Factors leading to a proliferation of server-side vulnerabilities:
• Rush to market
• Lack of security knowledge because of the new-ness of the languages;
• Easy access to frameworks that don’t prioritize security;
• Higher than average outsourced development;
• Lower security budgets for mobile applications;
• Assumption that the mobile OS takes full responsibility for security; and
• Weakness due to cross-platform development and compilation.
39

Insecure Data Storage
It is important to threat-model your mobile app to understand the information assets it processes and how
the underlying APIs handle those assets. These APIs should store sensitive information securely
Business Impact
• Identity Theft, Fraud
• Reputation Damage
• External Policy Violation (PCI)
Technical Impacts
• can result in data loss, in the best case, for one user. In the worst case, for
many users
Security Weakness
• File systems are easily accessible
• Rooting or jailbreaking a mobile device circumvents any encryption
protections.
Attack Vectors
• adversary physically attains the mobile device, the adversary hooks up the
mobile device to a computer with software.
Threat Agents
• an adversary that has attained a lost/stolen mobile device
• malware or a other repackaged app
40

Places where data being stored insecurely includes:
• SQLite databases
• Log Files
• Plist Files
• XML Data Stores or Manifest Files
• Binary data stores
• Cookie stores
• SD Card
• Cloud synced
Database Server
SD Card
41

Insufficient Transport Layer Protection
To find out if an application has sufficient transport layer protection, look at the application traffic through a
proxy
Business Impact
• Identity theft;
• Fraud, or
• Reputational Damage.
Technical Impacts
• exposes an individual user's data and can lead to account theft
• Poor SSL setup can also facilitate phishing and MITM attacks
Security Weakness
• This inconsistency leads to the risk of exposing data and session IDs to
interception
Attack Vectors
• targeted attacks are easier to perform
Threat Agents
• An adversary that shares your local network
• Carrier or network devices
• Malware on your mobile device.
42

Example
In the above example due to insufficient transport layer External attacker steals credentials and data off
Network whereas Internal attacker steals credentials and data from the internal network
43

Unintended Data Leakage
Unintended data leakage includes vulnerabilities from the OS, frameworks, compiler environment, new
hardware, etc. without a developers knowledge.
In mobile development, this is most seen in undocumented (or under-documented) internal processes
Business Impact
• Privacy Violations
• PCI Violations
• Reputational Damage; or Fraud
Technical Impacts
• extraction of the app's sensitive information via:-
• mobile malware,
• modified apps, or forensic tools.
Security Weakness
• information being placed into an insecure location on the mobile device
that other apps on the device may have open access to.
Attack Vectors
• use freely available forensic tools to conduct the attack
• use fully permissible API calls to conduct this attack.
Threat Agents
• mobile malware,
• modified versions of apps,
• an adversary that has physical access
44

The most seen in undocumented internal processes includes:
• The way the OS caches data, images, key-presses, logging, and buffers.
• The way the development framework caches data, images, key-presses, logging, and
buffers.
• The way or amount of data ad, analytic, social, or enablement frameworks cache
data, images, key-presses, logging, and buffers.
45

Poor Authorization and Authentication
Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally,
the authentication routine can be bypassed on jailbroken devices through run-time manipulation or
modification of the binary
Business Impact
• Reputational Damage;
• Fraud; or
• Information Theft.
Technical Impacts
• inability to detect the source of an attack, the nature of any underlying
exploits, or how to prevent future attacks.
Security Weakness
• Weaker authentication for mobile apps is fairly prevalent due to a mobile
device's input form factor
Attack Vectors
• bypass authentication by submitting service requests to the app's backend
server and bypass any direct interaction with app
Threat Agents
• through automated attacks that use available or custom-built tools.
46

Broken Cryptography
Insecure use of cryptography is common in most mobile apps that leverage encryption. There are two ways
that broken cryptography is manifested:
• the mobile app may use a process behind the encryption that is fundamentally flawed
• the mobile app may algorithm that is weak and can be directly decrypted by the adversary.
Business Impact
• Privacy Violations;
• Information Theft;
• Intellectual Property Theft
Technical Impacts
• will result in the unauthorized retrieval of sensitive information from the
mobile device.
Security Weakness
• due to weak encryption algorithms
• flaws within the encryption process.
Attack Vectors
• decryption of data via physical access to the device
• network traffic capture,
Threat Agents
• anyone with physical access to data that is encrypted improperly
• mobile malware acting on an adversary's behalf.
47

Shared Secret(Key) Shared Secret (Key)
Encrypt DecryptPlain Text Plain Text
Host 1 Host 2
Secure Distribution
Method
Insecure Communication
Channel
In cryptography issues
If the public key is shared then the encrypted data can be broken and in other case attacker
Attacks the communication channel or side where data is decrypted and plain text can be found without
Putting the effort in decrypting the data
48

Client Side Injection
The best way to find out if an application is vulnerable to injection is to identify the sources of input and
validate that user/application supplied data is being subject to input validation, disallowing code injection
Business Impact
• Fraud; and
• Privacy Violations.
Technical Impacts
• can be severe if app deals with more than one user account on a single
application or a shared device or paid-for content
Security Weakness
• malicious code is provided in the form of data that the threat agent inputs
to the mobile app through different means
Attack Vectors
• Almost any source of data can be an injection vector, including resource
files or the application itself.
Threat Agents
• anyone who can send untrusted data to the mobile app, including external
users, internal users, the application itself
49

Injection attacks on mobile devices target the following:
• SQL Injection: SQLite) can be subject to injection just like in web applications.
The threat of being able to see data using this type of injection is risky when your
application houses several different users, paid-for/unlockable content, etc.
• Local File Inclusion: File handling on mobile devices has the same risks as stated
above except it pertains to reading files that might be yours to view inside the
application directory.
1345 Enter
SELECT MOVIE, where
USERID= 1345
Mobile Application
50

Security Decisions Via Untrusted Inputs
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process
Communication (IPC) mechanism
Business Impact
• impacting and harming the integrity and confidentiality.
• Loss of reputation
Technical Impacts
• provides access of higher authorities and functionalities to an attacker
• bypass security mechanisms
Security Weakness
• Weak implementation of hidden functionality leads to granting higher
level permissions to an attacker
Attack Vectors
• can intercept intermediate calls and manipulate results via parameter
tampering.
Threat Agents
• entities that can pass untrusted inputs to the method calls
• users, malware and vulnerable apps.
51

Example
HTML or
Script
Injection
via
App
Attacker
Embeds
Iframe
<iframe
Src=“gma
il:
Abcd123?
Call></ifr
ame>
Gmail
app
Handles
this URL
scheme
Phone Call
is initiated
without
user
consent
Due to the IPC (Inter Process Communication) the mobile devices can accept all kind of data.
In the above example the attacker is sending an embedded call to another program in his
message
Then a phone call is initiated without the permission of the user which is a serious and most
found flaw in the mobile devices
52

Improper Session Handling
Improper Session Handling typically results in the same outcomes as poor authentication. Once you are
authenticated and given a session, that session allows one access to the mobile application. Mobile app code
must protect user sessions just as carefully as its authentication mechanism.
Business Impact
• Fraud;
• Information Theft; or
• Business Interruption
Technical Impacts
• Worst case: Impersonating admin
• Average Case:users lose control of their accounts
Security Weakness
• occurs when session token is unintentionally shared with the adversary
Attack Vectors
• physical access to the device
• network traffic capture
• malware on the mobile device.
Threat Agents
• Anyone or any mobile app with access to HTTP/S traffic, cookie data, etc.
53

How it is often done improperly?
• Failure to Invalidate Sessions on the Backend
• Lack of Adequate Timeout Protection
• Failure to Properly Rotate Cookies
• Insecure Token Creation
Proper Session Management
Login Logout
Status Main Activity
Splash
Status=1
Status=0
If(status.equals(1))
If(status.equals(0))
54

Lack of Binary Protections
If you are hosting code in an untrustworthy environment, you are susceptible to this risk. This includes mobile
clients, firmware in appliances, cloud spaces, or datacenters within particular countries
Business Impact
• Revenue Loss and Piracy;
• Intellectual Property Theft;
• User Experience Compromise.
Technical Impacts
• Analysis and Reverse Engineering
• Unauthorized Code Modification
Security Weakness
• can be analyzed, reverse-engineered, and modified by an adversary in
rapid fashion
Attack Vectors
• use an automated tool to reverse engineer the code and modify it
Threat Agents
• analyze and reverse engineer a mobile app's code, then modify it to
perform some hidden functionality.
55

Are You vulnerable to a binary attack?
• Can someone reverse engineer this app (Android specific) using an automated tool
like dex2jar?
• Can someone use an automated tool like Hopper or IDA Pro to easily visualize the
control-flow and pseudo-code of this app?
• Can someone modify the app’s presentation layer (HTML/JS/CSS) of this app within
the phone and execute modified JavaScript?
• Can someone modify the app’s binary executable using a hex editor to get it to
bypass a security control?
56

Weak Server Side Controls
Secure coding and configuration practices must be used on server-side of the mobile application.
Insecure Data Storage
• Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive
information assets.
• Consider providing an additional layer of encryption beyond any default encryption mechanisms
provided by the operating system
Broken Cryptography
• Reliance Upon Built-In Code Encryption Processes
• Secure Key Management Processes
• Creation and Use of Custom Encryption Protocols
• Avoid Use of Insecure and/or Deprecated Algorithms
58

Insufficient Transport Layer Protection
• Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive
information, session tokens, or other sensitive data to a backend API or web service.
• Account for outside entities like third-party analytics companies, social networks, etc. by using
their SSL versions when an application runs a routine via the browser/webkit.
• Never allow self-signed certificates, and consider certificate pinning for security conscious
applications.
• Only establish a secure connection after verifying the identity of the endpoint server using trusted
certificates in the key chain.
• If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL
channel.
Improper Session Handling
To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session
tokens properly over the life-cycle of a user’s mobile app session.
59

Unintended Data Leakage
• It is important to threat model your OS, platforms, and frameworks, to see how they handle the
following types of features:
• URL Caching (Both request and response)
• Keyboard Press Caching
• Copy/Paste buffer Caching
• Application backgrounding
• Logging
• HTML5 data storage
• Browser cookie objects
• Analytics data sent to 3rd parties
Lack of Binary Protections
Follow secure coding techniques for:
• Jailbreak Detection Controls;
• Checksum Controls;
• Certificate Pinning Controls;
• Debugger Detection Controls.
60

Client Side Injection
• SQL Injection: When dealing with dynamic queries or Content-Providers ensure you are using
parameterized queries.
• JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any WebViews
(usually the default).
• Local File Inclusion: Verify that File System Access is disabled for any WebViews
(webview.getSettings().setAllowFileAccess(false);).
• Intent Injection/Fuzzing: Verify actions and data are validated via an Intent Filter for all Activities.
Security Decisions Via Untrusted Inputs
• If there is a business requirement for IPC communication, the mobile application should restrict
access to a white-list of trusted applications
• Sensitive actions which are triggered through IPC entry points should require user interaction
before performing the action
• All input received from IPC entry points must undergo stringent input validation in order to
prevent input driven attacks
• Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being
read by third party applications under certain scenarios.
61

References
62
• http://www.securityweek.com/case-study-securing-web-applications
• https://www.appvigil.co/blog/2015/06/all-you-wanted-to-know-about-owasp-top-10-mobile-
security-project/
• http://www.owasp.org
• http://www.veracode.com/directory/owasp-top-10
• http://www.applicure.com/solutions/web-application-security

Web and Mobile Application Security

More Related Content

What's hot

Viewers also liked

Similar to Web and Mobile Application Security

Recently uploaded

Web and Mobile Application Security