SlideShare a Scribd company logo

Sql securitytesting

•Download as PPT, PDF•
•
Thilak Pathirage -Senior IT Gov and Risk Consultant
Thilak Pathirage -Senior IT Gov and Risk Consultant

This document discusses security testing for mobile and web applications. It covers security risks for Android apps, including actions malicious apps could take like gaining ungranted permissions or spreading automatically. It also discusses Android OS security features and how mobile app permissions work. Other topics include signed apps/app stores, problems with permissions, an example attack exploiting browser vulnerabilities, and designing apps with security best practices like least privilege and input sanitization in mind. The document concludes with discussions of security for mobile apps that interface with web apps and the importance of using secure protocols like HTTPS for web traffic.

Related slideshows

Securing Servers in Public and Hybrid Clouds
Securing Servers in Public and Hybrid CloudsSecuring Servers in Public and Hybrid Clouds
Securing Servers in Public and Hybrid Clouds
 
Best-Practices-Web-Usability
Best-Practices-Web-UsabilityBest-Practices-Web-Usability
Best-Practices-Web-Usability
 
Data loss prevention by using MRSH-v2 algorithm
Data loss prevention by using MRSH-v2 algorithm Data loss prevention by using MRSH-v2 algorithm
Data loss prevention by using MRSH-v2 algorithm
 
1 of 36
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 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 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 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 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 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
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.
Designing for security
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 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 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 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 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 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 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 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 Data storage location • Where is your app storing its data, and why? Is it secure?
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 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 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)
Web security
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 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 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 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 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 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 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';
Thinking like an attacker: Finding vulnerabilities
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 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 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 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 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 Other attacks • Attacking GET parameters • Attacking hidden input fields • Attacking cookies • Cross-site request forgery (CSRF) • ...
36 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.

More Related Content

Sql securitytesting

  • 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
  • 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)
  • 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) • ...
  • 36. 36 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.