![18
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;
}](https://image.slidesharecdn.com/no-241020201848-221f6c05/85/Security-Testing-for-Mobile-and-Web-Apps-18-320.jpg)
Security Testing for Mobile and Web Apps
- 1. 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/
- 2. 2 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
- 3. 3 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
- 4. 4 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>
- 5. 5 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?
- 6. 6 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
- 7. 7 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.
- 9. 9 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."
- 10. 10 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.
- 11. 11 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
- 12. 12 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.
- 13. 13 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
- 14. 14 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.
- 15. 15 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?
- 16. 16 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?
- 17. 17 Data storage location • Where is your app storing its data, and why? Is it secure?
- 18. 18 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; }
- 19. 19 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.
- 20. 20 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)
- 21. Web security
- 22. 22 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 $$$.
- 23. 23 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
- 24. 24 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.
- 25. 25 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.
- 26. 26 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!
- 27. 27 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.
- 28. 28 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';
- 29. Thinking like an attacker: Finding vulnerabilities
- 30. 30 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
- 31. 31 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...
- 32. 32 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
- 33. 33 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
- 34. 34 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
- 35. 35 Other attacks • Attacking GET parameters • Attacking hidden input fields • Attacking cookies • Cross-site request forgery (CSRF) • ...