CSE 403
Lecture 20
Security Testing for Mobile and Web Apps
Reading:
Android Apps Security, Ch. 2-3 (Gunasekara)
How to Break Web Software, Ch. 2-5 (Andrews/Whittaker)
slides created by Marty Stepp
http://www.cs.washington.edu/403/
Android security risks
• What are some security risks you can think
of that can affect an Android phone?
– What are actions a malicious app could take?
• Examples:
– uses a bug or security vulnerability to gain ungranted permissions
– shows the user unsolicited messages (especially commercial)
– resists (or attempts to resist) the user's effort to uninstall it
– attempts to automatically spread itself to other devices
– hides its files and/or processes
– discloses the user's private information to a third party w/o consent
– destroys the user's data (or the device itself) without w/o consent
– impersonates the user (such as by sending email or buying things)
– drains the phone's battery, data bytes/minutes, SMS/MMS remaining
– otherwise degrades the user's experience with the device
2
Android OS security
• The Android operating system provides security:
– Unix-based file/directory permission model
– process memory isolation and memory protection
– filesystem encryption
– per-app access to hardware devices
– per-app restrictions on memory/CPU usage, other
resources
• network/data connection
• camera
• location (GPS) data
• bluetooth
• SMS/MMS
• ...
– DRM framework 3
Mobile app permissions
• Apps must declare which permissions they need
– e.g. use internet; write to local files; look at contacts;
use Bluetooth; access GPS location; send SMS
– user must manually give permission for actions
• Fine-grained access control in Manifest XML file
– File/URL-specific permissions
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.app.myapp" >
<uses-permission android:name="android.permission.RECEIVE_SMS" />
...
</manifest>
4
Signed apps/stores
• signed apps: Coded with a private developer key
– On Android / iPhone, apps must be signed in market
– manual approval reduces chance of rogue apps
– any app bought in official App Store / Market is
generally thought of as having being audited
• Is this true for Apple store apps?
• Is this true for Google Play Market apps?
• App store users can rate the apps and comment
– Do you feel that an app is more likely to be secure:
• If it is from a publisher/company you already know?
• If a friend of yours has it installed?
• If it costs money?
5
Problems with Android
• Apps can ask for too many permissions.
– Users don't really understand permissions.
– Users are overwhelmed and just click "Yes"
– Now the app can do almost anything.
• Updates to an app can change its permissions.
– example: recent Facebook app update
– Users often click "Yes" if they already trust the app.
– "privilege escalation"
• Spammy apps
– resist attempts to uninstall
– show ads that are like system/OS UI
– disclose or damage the user's personal information data
– impersonates the user
6
Example attack
• Android 2.2 / 2.3 had vulnerabilities.
– Browser could download a HTML page.
– The page contains JS code.
– The JS code can self-execute later
in a "local" context.
– This has higher permissions and can
modify the local file system.
• App ABC stores sensitive data on the local file system.
– The data is financially important.
– It is saved as a file in plain-text.
– The above malicious browser JS code can read and access
it.
7
Designing for security
Methods of security
• Security through obscurity: Relying on the fact that
attackers don't know something needed to harm you.
– Example: "If an attacker pointed their browser to
http://foo.com/passwords.txt, they'd get our passwords.
But nobody knows that file is there, so we are safe."
– Example: "Our app saves its sensitive user data using
SQLite which ends up as a file on the local file system."
– Example: "Our authentication database goes down for 2
minutes every night at 4am. During that time any user
can log in without restrictions. But no one knows this,
and the odds of a login at that time are miniscule."
9
Secure authentication
• Force users to log in to your system before performing
sensitive operations
• Use secure protocols (https, etc.) to prevent sniffing
– Some sites use HTTPS only for login page, then switch
back to regular HTTP for future page views. Is this bad?
• Force users to use strong passwords
– not "password", or "abc", or same as their user name, etc.
10
Principle of least
privilege
• principle of least privilege:
Granting just enough authority to get the job done (no
more!).
– Examples:
• Code should not "run as root" or as a highly privileged user
unless absolutely necessary.
• A web server should only be given access to the set of HTML
files that the web server is supposed to serve.
– Turn off unnecessary services on your server
• disable SSH, VNC, sendmail, etc.
• close all ports except 80, and any
others needed for web traffic
11
Sanitizing inputs
• sanitizing inputs: Encoding and filtering untrusted
user input before accepting it into a trusted system.
– Ensure that accepted data is the right type, format,
length...
– Disallow entry of bad data into a graphical form.
– Remove any SQL code from submitted user names.
– Encode/sanitize input text that is displayed back to the
user.
12
Verifying that code is
secure
• Before code is written:
– considering security in the design process
• As code is being written:
– code reviews
– code security audits
– pair programming
• After code has been written:
– walkthroughs
– system security audits
– system/functional security testing
– penetration tests
13
Security audits
• security audit: A series of checks and questions to
assess the security of your system.
– can be done by an internal or external auditor
– best if done as a process, not an individual event
• penetration test: Targeted white-hat attempt to
compromise your system's security.
• risk analysis: Assessment of relative risks of what can
go wrong when security is compromised.
14
Security audit questions
• Does your system require secure authentication with passwords?
• Are passwords difficult to crack?
• Are there access control lists (ACLs) in place on network devices?
• Are there audit logs to record who accesses data?
• Are the audit logs reviewed?
• Are your OS security settings up to accepted industry levels?
• Have all unnecessary applications and services been eliminated?
• Are all operating systems and applications patched to current levels?
• How is backup media stored? Who has access to it? Is it up-to-date?
• Is there a disaster recovery plan? Has it ever been rehearsed?
• Are there good cryptographic tools in place to govern data encryption?
• Have custom-built applications been written with security in mind?
• How have these custom applications been tested for security flaws?
• How are configuration and code changes documented at every level? How
are these records reviewed and who conducts the review?
15
Data classification
• data classification table: For each kind of data your
app saves/uses, ask yourself:
– Is this information personal or sensitive in nature?
– What does my app do with this information?
– Where and in what format is it saved?
– Is it sent over the network?
– (for all above) Does it need to be? Can I reduce my use?
16
Data storage location
• Where is your app storing its data, and why? Is it
secure?
17
Encryption
• You can easily encrypt data in Android just
before/after saving it to the device's SD card or local
database.
private static byte[] encrypt(byte[] key, byte[] data) {
SecretKeySpec sKeySpec = new SecretKeySpec(key, "AES");
Cipher cipher;
byte[] ciphertext = null;
try {
cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, sKeySpec);
ciphertext = cipher.doFinal(data);
} catch (NoSuchAlgorithmException e) {
Log.e(TAG, "NoSuchAlgorithmException");
} catch (InvalidKeyException e) {
Log.e(TAG, "InvalidKeyException");
} catch (Exception e) {
Log.e(TAG, "Exception");
}
return ciphertext;
}
18
Mobile+web apps
• OWASP Top 10 issues for mobile
apps that talk to web apps:
– Identify and protect sensitive data on the mobile device.
– Handle password credentials securely on the device.
– Ensure that sensitive data is protected in transit.
– Implement user authentication and session management
correctly.
– Keep the back-end APIs (services) and the platform (server)
secure.
– Perform data integration with third party services/apps securely.
– Pay specific attention to the collection and storage of consent for
the collection and use of the user’s data.
– Implement controls to prevent unauthorized access to paid-for
resources (e.g., wallet, SMS, and phone calls).
– Ensure secure distribution/provisioning of mobile applications.
– Carefully check any runtime interpretation of code for errors.
19
Secure web (HTTPS)
• man-in-the-middle attack:
– unauthorized third party
can hear web traffic
on its hops between
client and server
• For security, all web traffic
in your app should use
HTTPS secure protocol.
– built on Secure Socket Layer (SSL)
20
Web security
Denial-of-Service (DoS)
• Denial of Service (DoS) attack:
Attacker causes web server to be unavailable.
• How attack is performed:
– Attacker frequently requests many pages from your web site.
• distributed DoS (DDoS): DoS using lots of computers
– Your server cannot handle this many requests at a time, so it
turns into a smoldering pile of goo (or just becomes very
slow).
• Problems that this attack can cause:
– Users cannot get to your site.
– Online store's server crashes -> store loses potential revenue.
– Server may crash and lose or corrupt important data.
– All the bandwidth used by the DoSers may cost you $$$. 22
Packet sniffing
• packet sniffing: Listening to traffic sent on a network.
– Many internet protocols (http, aim, email) are unsecure.
– If an attacker is on the same local network (LAN) as you,
he can:
• read your email/IMs as you send them
• see what web sites you are viewing
• grab your password as it's being sent to the server
• solutions:
– Use secure protocols (ssh, https)
– Encryption
– Don't let creeps on your LAN/wifi
23
Password cracking
• password cracking:
Guessing the passwords of privileged users of your
system.
• How attack is performed:
– brute force attack: Attacker uses software that
sequentially tries every possible password.
– dictionary attack: Attacker uses software that sequentially
tries passwords based on words in a dictionary.
• every word in the dictionary
• combinations of words, numbers, etc.
• What you can do about it:
– Force users to have secure passwords.
– Block an IP address from logging in after N failed attempts.
24
Phishing/social
engineering
• phishing: Masqueraded mails or web sites.
– social engineering: Attempts to manipulate users, such
as fraudulently acquiring passwords or credit card
numbers.
• Problems:
– If trusted users of your
system are tricked into
giving out their personal
information, attackers
can use this to log in as
those users and
compromise your system.
25
Privilege escalation
• privilege escalation: Attacker becomes able to run
code on your server as a privileged user.
– Example: Perhaps normal users aren't able to directly
query your database. But an attacker may find a flaw in
your security letting him run as an administrator and
perform the query.
– Once you're running as root,
You own the server.
You can do anything you want!
26
Cross-site scripting
(XSS)
• cross-site scripting: Causing one person's script code
to be executed when a user browses to another site.
– Example: Visit google.com, but evil.com's JavaScript runs.
• How attack is performed:
– Attacker finds unsecure code on target site.
– Attacker uses hole to inject JavaScript into the page.
– User visits page, sees malicious script code.
27
SQL Injection
• SQL injection:
Causing undesired SQL queries to be run on your
database.
– Often caused when untrusted input is pasted into a SQL
query
PHP: "SELECT * FROM Users WHERE name='$name';";
– specify a user name of: x' OR 'a'='a
SELECT * FROM Users WHERE name='x' OR 'a'='a';
28
Thinking like an
attacker:
Finding vulnerabilities
Panning for gold
• View Source, and look for:
– HTML comments
– script code
– other sensitive information in code:
IP/email addresses, SQL queries, hidden fields,...
– watch HTTP requests/responses
• look for hidden pages, files, parameters to target
– error messages sent to your browser by app
• 200: OK 400: Invalid request
• 403: Forbidden 404: File not found
• 500: Internal server error
30
Input forms
• Forms let users pass parameters to the web server.
• Parameters are passed using GET or POST requests.
– GET: parameters are contained in the request URL.
http://www.google.com?q=Stephen+Colbert&lang=en
– POST: parameters are contained in the HTTP packet
header.
• harder for the user to see, but no more secure than GET
• Forms provide a rich attack ground...
31
Form validation
• validation: Examining form parameters to make sure
they are acceptable before/as they are submitted.
– nonempty, alphabetical, numeric, length, ...
– client-side: HTML/JS checks values before request is sent.
– server-side: JSP/Ruby/PHP/etc. checks values received.
• Some validation is performed by restricting the user's
choices.
– select boxes
– input text boxes with
maxlength attribute
– key event listeners that
erase certain key presses
32
User input attacks
• Bypassing client-side input restrictions and validation
– maxlength limits on an input text field
– choices not listed in a select box
– hidden input fields
– modifying or disabling client-side JavaScript validation
code
33
Guessing files/directories
• security through obscurity: Many reachable
files/resources are hidden only by the fact that there is
no link to them.
• Try common file/folder/commands to see what
happens:
– /etc/passwd , /etc/shadow , cat, ls, grep
– guess file names based on others
• page11.php --> page12.php
• loginfailure.jsp --> loginsuccess.jsp
• accounts/fred.html --> accounts/sue.html
– brute force / web spiders
– port scanners
34
Other attacks
• Attacking GET parameters
• Attacking hidden input fields
• Attacking cookies
• Cross-site request forgery (CSRF)
• ...
35
Web attack exercise
• We are taking CSE 144, which uses an online turnin system.
– We want to hack it because we are evil.
• Our goals:
– We want to cheat on Homework Assignment 7, Song.java. We
want to find a way to submit a perfect working solution without
doing any real work.
– We got a low grade on a past assignment, so if possible, we
want to set our past grades to be higher than they are now.
– Our enemy is fellow classmate Felix Chu. We want to find out
his personal information (password, email, student ID, grade,
etc.).
– We don't like the course instructor, Marty Stepp. We want to
make the turnin page print an embarrassing message about
him.
36
