The document summarizes key points about web application security vulnerabilities and how to address them. It discusses common vulnerabilities like parameter manipulation, cross-site scripting, and SQL injection that occur due to improper validation of user input. It emphasizes the importance of validating all user input on the server-side to prevent attacks, and not storing sensitive values in cookies or hidden form fields that can be manipulated by attackers.

1. Workshop on Web Application Security

2. Overview Course designed to Teach participants about most common web application vulnerabilities Identify importance of having a secure web application architecture How to integrate security within your web applications

3. Overview Web Applications Sect-1 Security threats revisit Sect-1 Web applications security Parameter Manipulation Cross Site Scripting (XSS) SQL Injection Implementing Web Application Security Resources Google Hacking Wrap-up

4. Web Application

5. Evolution of the Internet Initially we had static HTML based websites

6. Evolution of the Internet Replaced with dynamic multi-technology based web applications ‘ Dynamic’ means different things to different people – Interactive forms – Customizing page content based on client attributes – Reactive pages

7. Popularity of web apps Easy deployment and no installation hassles Very easy to change and update functionality Easy accessibility for users Organizations “ web-fying ” all their applications E-commerce sites Intranet portals

8. Typical structure of a Web Application HTTP allowed through port 80 Firewalls and other simple boundary devices lack some degree of intelligence when it comes to observing, recognizing, and identifying attack signatures that may be present in the traffic they monitor and the log files they collect. Without sounding critical of such other systems’ capabilities, this deficiency brought in Intrusion Detection systems

9. Today’s threat landscape Organization nowadays do a lot of things right as far as security goes Firewalls and other perimeter devices are deployed Servers are regularly patched Network traffic is encrypted Continuous monitoring via security audits and Network scanning tools However security bugs/vulnerabilities present at the application layer (code level) are usually ignored Also network layer has some solved vulnerables

10. Network Level Attack

11. Network a mean of breach

12. Security threats revisit

13. IP Spoofing Smurf Attack Denial of service attack Fragmentation Attack

14. IP Spoofing Any station can send packets pretending to be from any IP address Replies will be routed to the appropriate subnet Route asymmetry So, attacker might not get replies if spoofing a host on a different subnet For some attacks this is not important Analogy Nothing prevents you from physically mailing a letter with an invalid return address, or someone else’s, or your own. Likewise, packets can be inserted in the network with invalid or other IP addresses.

15. IP Spoofing with Amplification Use broadcasts pretending to originate from victim All replies go back to victim This may use any IP protocol (ICMP, TCP, UDP) Any application or service that replies using these protocols Famous attack: Smurf (using ICMP) DoS CERT® Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks Many others Smurf Amplifier Registry: http://www.powertech.no/smurf/

16. Smurf Attack If an attacker wants to map your network, the trivial way is to ping all the IP addresses in your network... Therefore, if you allow pings, your network is exposed. Ping a broadcast address, with the (spoofed) IP of a victim as source address All hosts on the network respond to the victim The victim is overwhelmed Keys: Amplification and IP spoofing Protocol vulnerability; implementation can be “patched” by violating the protocol specification, to ignore pings to broadcast addresses ICMP echo just used for convenience All ICMP messages can be abused this way "Fraggle" is the equivalent, using UDP instead of ICMP Sol : Ingress filtering , Egress filtering Drop inbound broadcasts Drop outbound broadcasts

17. Denial of Service Attack A denial-of-service attack ( DoS attack ) or distributed denial-of-service attack ( DDoS attack ) is an attempt to make a computer resource unavailable to its intended users. Although the means to carry out, motives for, and targets of a DoS attack may vary, it generally consists of the concerted efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.

18. DOS Attack Methods The five basic types of attack are: Consumption of computational resources, such as bandwidth, disk space, or processor time Disruption of configuration information, such as routing information. Disruption of state information, such as unsolicited resetting of TCP sessions. Disruption of physical network components. Obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately

19. Fragmentation Attack Networks have different frame sizes “ MTU” is the "Maximum Transmission Unit" Fragmentation allows oversized packets to be split to fit on a smaller network Reassembly is difficult Have to keep track of all fragments until packet is reassembled (Last fragment lost) Resource allocation is necessary before all validation is possible (overlapping fragments) Lots of fragments from different packets can exhaust available memory (Packet reassembly generate IP packet larger then legal size) Perfect grounds for resource exhaustion attacks Fragmentation Basics

20. Fragmentation Attack, countermeasures Firewalls and intrusion detection systems (IDS) may reassemble packets differently from how the attacked operating systems do it Perhaps rules are interpreted before reassembly is complete Fragrouter IDS evasion toolkit http:// packetstorm.widexs.nl/UNIX/IDS/nidsbench/fragrouter.html Fragment packets to trick firewalls and IDS Dug Song (1999)

21. Firewalls and Encryption do NOT protect against Web Application Vulnerabilities Only tool required is a web browser ! HTTP allowed through port 80

22. Problems Nearly 70-80% of all vulnerabilities being reported are web application vulnerabilities Quickly becoming the Easiest way to compromise hosts For web applications to properly work ,you have to allow traffic (port 80) through the firewall.

23. A Gartner study indicates that 75% of security breaches are due to flaws in software

24. Web Application Security Issues Web applications effectively extend an organization’s security perimeter Easy accessibility for attackers as well Over reliance on SSL Most web-applications connect back to databases containing confidential information Lack of security awareness amongst developers

25. What makes web apps so vulnerable? Unlike OS, Firewalls and Intrusion Detection Systems; applications vary from organization to organization. Coding mistakes due to pressure to build and deploy system. Special skills required to secure web apps

26. Misconceptions We are secure: we have a firewall Great at blocking ports Does not detect malicious input We are secure: we use SSL Great at encrypting traffic Does not validate application input

28. Web Application Security

29. Basic principle behind web app attacks “ Make the web application do something the developer never intended for it to do”

30. Basic principle behind web app attacks

31. Basic principle behind web app attacks

32. Problem: user input All user input is inherently evil Malicious input can: Enable attacker to access your internal databases Damage limited only by privilege of data account Alter flow of your web applications Allow attackers to use your website to launch attacks against other users

33. Root Cause: Client input Attacks are injected through Text based forms in Web pages Manipulating URL addresses Cookie tampering Manipulation of hidden fields

34. Common vulnerabilities Cause crashing of a process Buffer Overflow Vulnerability What can an attacker do ? Parameter manipulation Change values of sensitive information Cross Site Scripting Impersonate a trusted site and steal user information SQL Injection Access all data in your database resulting in a total data breach

35. Buffer Overflows

36. Buffer Overflows

37. How to Avoid

38. Parameter manipulation

39. Parameter Manipulation Web pages are “stateless” i.e. they do not remember what data was on the previous page Developers need some way to keep track or “persist” the data as users go from page to page Shopping Cart Product Details Order Details Check out

40. Parameter Manipulation Several ways to do this Temporary databases Cookies User Sessions Hidden Fields in Web pages URLs We’re concerned about Hidden Fields and Cookies

41. Hidden Fields Developers use hidden fields to store data needed between pages. These fields are not visible to the users <input type=&quot;hidden&quot; id=“price” value=1000>

42. Hidden-field tampering Possible for an attacker to take advantage and change values stored in hidden fields The technique Look for <input type=&quot;hidden&quot; … > tags Submit bogus requests with modified value attributes <input type=&quot;hidden&quot; id=&quot;price“ value=&quot;10000.00&quot;> price=&quot;1.00&quot;

43. Hidden-field tampering <input type=&quot;hidden&quot; name=“txtprice1“ value=&quot;1000.00&quot;> <input type=&quot;hidden&quot; name=“txtprice2“ value=“500.00&quot;> Sample Shopping Cart

44. Hidden-field tampering Tamper Data : Firefox add-on which allows you to intercept and change values submitted by a page.

46. Hidden-field tampering Change the price ?

47. Hidden-field tampering Changing the value of the hidden price field gives us a rather steep discount !

48. Cookies Same principle as Hidden Fields Usually used by websites to “ Remember ” users when they re-visit a website Cookies can contain following: UserIDs Email Addresses Discount values

49. Cookies Same can be edited at the client side

50. Defending against parameter manipulation Do not: Store sensitive values on the client Do: Encrypt your data Maintain sensitive data on the server Validate input parameters

51. Cross Site Scripting (XSS)

52. Allows attackers to inject their own malicious scripts onto web pages and have it executed by the user’s browser Usually occurs when web pages display back the text that was entered by the user Cross Site Scripting (XSS) Welcome back Taimur ! Login failed for ‘ Taimur ’ Your search for ‘ Taimur ’ returned 0 results

54. What is cross site scripting? Vulnerability commonly seen in : Search results that display back the text that was entered Error messages that display the text that caused the error Forms which are filled out whose values are later displayed to the user Web message boards where users can post messages

55. What is cross site scripting? XSS allows attacker to: Perform malicious actions in a client’s Web browser Perform Identity Theft Spy on user’s web browsing habits Redirect users to other sites As of 2007, cross-site scripting carried out On websites were roughly 80% of all Documented security vulnerabilities do it

56. How XSS attack can happen Response.Write(&quot;Welcome &quot; & Request.QueryString(&quot;UserName&quot;)) www.vulnerable.asp?username=Taimur will display “ Welcome Taimur” Web Application takes name as a parameter from website’s URL and displays it Attacker abuses this by sending his own script in the [username] parameter which will be executed by the browser www.vulnerable.asp?username=<script>alert(‘XSS’);</script>

57. How XSS attack can happen If parameter causes web application to display below message, XSS attack is successful : But these scripts are only being executed on the attackers own computer ? Attacker now knows its possible it insert his own malicious scripts into the URL and have them executed by the web application

58. How XSS attack can happen Attacker now crafts a malicious URL sends this to a user via email to trick him into giving up his UserID and Passwords

59. Phishing attack via Cross Site Scripting 1. XSS Attack 2. Website vulnerable to XSS 5. Victim Information stolen 3. Create email with malicious hyperlink 4. Email Sent to victim

60. How XSS attack can happen Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross Site Scripting attacks. In these cases, an attacker can post a message to the board which can be viewed by other users later on.

61. XSS Worms Self-replicating XSS code usually found in social networking websites e.g. Orkut, Facebook, Myspace etc. Abuses “ circle of trust ” concept to quickly infect user profiles “ Samy ” Worm which infected MySpace in 2005 was able to infect 1 million profiles in 24 hours

62. Comparison of Samy with other worms First 24 hours of worm propagation

63. Defending against XSS Disable scripting (Not feasible) Filter all user input before accepting it Filter all user input before displaying it Do not: Trust user input Display on the page anything entered by the user unless you have validated it

64. Defense tactics Write an HTMLEncode

65. HTML Protection Encoding user supplied output can also defeat XSS vulnerabilities by preventing inserted scripts from being transmitted to users in an executable form. Applications can gain significant protection from javascript based attacks by converting the following characters in all generated output to the appropriate HTML entity encoding: &#45; - &#43; + &#59; ; &#37; % &#35; # &#41; ) &#40; ( &apos; or &#39; ' &quot; or &#34; &quot; &amp; or &#38; & &gt; or &#62; > &lt; or &#60; < Encoding Character HTML Entities

66. Phishing counter-measures IE8 will have an XSS filter for protecting against cross site scripting attacks

67. NoScript Award winning Firefox add-on All Javascript is blocked by default User authorizes which Javascript will execute on the page Cumbersome but easily the best browser based protection against XSS

68. SQL Injection

69. SQL stands for Structured Query Language and allows us to access a database SQL can: retrieve data from a database insert new records in a database delete records from a database update records in a database What is SQL?

70. UserID: Test Password : 123 Select * from Users where UserID = ‘Test’ and Password = ‘123’; Web Applications take user input and build an SQL statement which they send to the database Drop example

72. UserID: Test; drop table users ; -- Password : 123 Select * from Users where UserID = ‘Test’; drop table users ; -- and Password = ‘123’; Web Applications take user input and build an SQL statement which they send to the database

73. What is SQL injection? The process of attacker adding his own SQL Statements in user input Used by attackers to Gain confidential information (Credit Card numbers, Account details etc.) Bypass authorization Perform unauthorized updates In worst case scenarios cause a total denial of service attack

74. What is SQL injection? SQL statements “injected” into an existing SQL command Injection occurs through : Input fields (e.g. UserID and Password entry) Query string (values added to website’s URL) Manipulated values in HTML

75. Defaults or Vulnerable

76. How do attackers know? Insider Information Trial and error Error messages often reveal too much Malicious user can force an error to discover information about the database Inserting a simple ‘ into a login field can tell a hacker if a page is vulnerable of not

79. How do attackers know?

80. How do attackers know?

81. SQL Injection attack on U.N.

82. Worst case scenario With the right privileges the user can access ALL databases on the server Once a malicious user can access the database, they are likely to use: xp_cmdshell - Access to the underlying OS xp_grantlogin - Database users xp_regread - Read registry keys Find it

83. Some valid arguments by web-app owners “ What if my website doesn't connect to any critical database ?” “ I don’t store any Credit Card numbers or personal information !” “ There is no information to steal”

84. It gets worse …

85. Malware Infection via SQL Injection

86. The new landscape Lets take a look at the big picture Malware easily poses one of the biggest security threats to both people and organizations today

87. Malware : Changing threat landscape Used to be about DOS attacks, bragging rights, website defacement Has now become a full-fledged industry generating billions of dollars in revenue Its now about making $$$$

88. Malware : Changing threat landscape Attacker are motivated to find more and more ways to steal information and sell this on underground black markets All this without drawing attention to themselves What sort of information are we talking about ?

89. What’s for sale ?

90. Malware spreading techniques Email Operating System vulnerabilities Browser weaknesses Remote Access Trojans Phishing Insecure Web Applications !!

91. SQL injection as a way to spread malware Identify a high profile website vulnerable to SQL injection Launch an SQL injection attack that fills the database with malicious scripts . These scripts will download malware (viruses, Trojans, worms, keyloggers etc.) from a remote server/location Anytime the website is visited, the malicious script is executed and the visitor’s computer infected.

92. Check if website is vulnerable to SQL injection Insert malicious <Script> tags in database

93. Before Injection After Injection

94. User visits compromised website Malicious script embedded in the database is executed Malware is downloaded onto the user’s PC

95. U.S. Sony Playstation website incident In July 2008, Sony’s US based website was SQL injected to serve malicious script Visitors would receive false warnings that their PC was infected with viruses and worms Goal was to fool visitors into buying fake security products

96. Automated Mass SQL Injections Disturbing new trend which dominated 2008 SQL injections are usually targeted attacks specifically tailored for each website. Attackers have figured out a way to automate the process

97. Automated Mass SQL Injections Attackers use an automated utility to locate websites that are vulnerable to SQL injection. Utility injects malicious scripts into the websites Same attack as before but MASSIVE spread. Hundreds to thousands of websites can be compromised

98. Mass SQL injections

99. Mass SQL injections

100. Automated Mass SQL Injections

101. Automated Mass SQL Injections Sophos Security threat report for 2009 Biggest malware threats: SQL Injection attack against websites Report predicts that SQL injection will be primary way of distributing web borne malware in the future Mass SQL Injection attacks dominated 2008

104. Automated Mass SQL Injections http://www.microsoft.com/technet/security/advisory/954462.mspx

105. SQL Injection Defense It is quite simple: input validation Check all input Web Applications should not directly build SQL statements based on user input This enables malicious input to be injected

106. SQL Injection Defense The real challenge is making best practices consistent through all your code Enforce &quot;strong design&quot; in new applications You should audit your existing websites and source code Set rs = cn. Execute(“Select * from Users where UserID = ‘” & request.form(“txtuserid”) & “’ and password = ‘” & request.form(“txtpassword”)”’”

107. Follow the Least Privilege principle Web Application should have least necessary privileges to access the database Do not allow Web Application to access database with following accounts: “ SA”,”DBA”,High-privilege user account Sys, System , Scott , MdSys, IIUSER_ORA Harden your Database Servers

108. SQL Injection Defense Fail intelligently i.e. Error messages should be customized NOT to display any information about what technology the web application is using. “ The application experienced an error and could not continue. The error has been logged for administrative purposes. Please click here to try again”

109. Implementing Web Application Security in your organization

110. Implementing Web App. Security By no means the task of a single person Must be embraced at multiple levels Each player must be aware of their responsibilities

111. The Web Developer

112. Role of the Web Developer Most critical (and most overlooked) role in web application security Developers (unintentionally) introduce the majority of security bugs Programmer’s job is to quickly develop and deploy the web application. NOT to make sure its secure Security is seen as a delaying factor

113. Role of the Web Developer Developers must be trained regarding the following : Input validation as the key in defensive programming Validating on the Server; NOT on the client Remember the least privilege principal

114. 25 most dangerous programming errors Released by SANS in January 12, 2009 Consensus list amongst security experts of the 25 most dangerous programming errors that lead to security bugs Intended as a reference for programmers and vendors on how to secure their code http://www.sans.org/top25errors/

115. 25 most dangerous programming errors We’ve already discussed some of these: CWE-20: Improper Input Validation It's the number one killer of healthy software …… CWE-116: Improper Encoding or Escaping of Output root of most injection-based attacks……..

116. 25 most dangerous programming errors CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection') Attackers can influence the SQL that you use to communicate with your database CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting') one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications... And so on …

117. IT Management

118. Role of IT Management Build up your Developers and QA unit’s security skills through awareness/training Ensure that QA staff also test web apps from a security perspective

119. Hacme Bank (www.foundstone.com) Training application with built-in vulnerabilities Designed to teach developers / QA staff how to build secure software

120. The IT Auditor / IT Security Officer

121. Role of IT Security / IT Auditor Last line of defense against insecure web applications

122. Role of IT Security / IT Auditor Ensure that all web apps are subject to security reviews before deployment Two levels of security reviews Web Application Security Scanning Source Code review

123. Security Testing “ Catch & Patch ” reactive approach Can be cumbersome in an organization running hundreds of web applications Identify and prioritize high risk web applications For effectiveness both manual and automated testing should be performed

124. Commercial Scanners No. Security Scanner URL 1. Acunetix Web Vulnerability Scanner http://www.acunetix.com 2. Watchfire Appscan http://www.watchfire.com/products/appscan/default.aspx 3. Milescan Web Security Auditor http://www.milescan.com/hk/ 4. HP WebInspect software https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201-200%5E9570_4000_100__

125. Security Testing What automated scanning tools excel at: Testing for 100s of common vulnerabilities and misconfigurations that are impractical to test for manually. Ability to schedule automated scanning/testing for off-production hours to avoid conflicts.

126. Security Testing What automated scanners have problem with: Identifying a lack of authorization checking (when it should be applied but isn't) Detailed exploits that require intelligent feedback and analysis White box testing – Automated tools are most effective at ‘guessing’ and using known signatures to identify issues. Software code reviews may find many more lurking issues that the tools can not, especially with custom developed software.

127. Security Testing Common Issues Testing can adversely impact a system being scanned. Performance issues and crashing can happen. It is usually difficult to know what the impact will be before scanning on any given web/app or database server. The most rigorous testing usually requires special planning and may overload log files, set off IDS sensors and leave ‘junk’ application data. Information overload and false positives. COST !!!

128. Freely available tools No. Security Scanner URL 1. Free Cross Site Scripting Scanner http://www.acunetix.com/cross-site-scripting/scanner.htm 2. Security Compass Tools http://www.securitycompass.com/exploitme.shtml 3. Microsoft Source Code Analyzer for SQL Injection http://www.microsoft.com/downloads/details.aspx?FamilyId=58A7C46E-A599-4FCB-9AB4-A4334146B6BA&displaylang=en 4. HP Scrawlr (free tool for SQL injection) https://h30406.www3.hp.com/campaigns/2008/wwcampaign/1-57C4K/index.php?mcc=DNXA&jumpid=in_r11374_us/en/large/tsg/w1_0908_scrawlr_redirect/mcc_DNXA

129. Exploit-Me by Security Compass Exploit-Me is a suite of Firefox web application security testing tools designed to be lightweight and easy to use. XSS-Me is the Exploit-Me tool used to test for reflected XSS vulnerabilities. SQL Inject-Me is the Exploit-Me tool used to test for SQL Injection vulnerabilities. http:// www.securitycompass.com/exploitme.shtml

130. Exploit-Me by Security Compass

131. Exploit-Me by Security Compass

132. Source Code Reviews Much more intensive than security testing Nearly all web application security issues reside in the source code Can find issues that security scanners will miss One of the most neglected security areas

133. Global Information Security Survey – 2008

134. Review Code Review is a must ! UserId = request.form(“txtuserid”) Password = request.form(“txtpassword”) If UserID = “ DEVELOPER ” then /* Give access to all modules */ .. else String = “Select * from UserTable where UserId = ‘”& UserID & “’ and Password = ‘” & Password & “’” End if Eliminate backdoors

135. Source Code Reviews Source Code reviews are usually seen as unnecessary and a delaying factor Make a business case for management Remember that the earlier security is considered the cheaper and easier it will be to implement.

136. Cost of fixing a security flaw increases as software goes into Production

137. Sample Case Study Your organization’s corporate website is accessed by an attacker via SQL injection. Several 100’s of customer records are compromised. How much would it cost to fix this during : Production ? QA?

138. Sample Case Study Costs to fix during Production : Application downtime ($) Incident Response ($) Consultancy ($) Re-testing and validation ($) Fines ($) Customer good will (???)

139. Sample Case Study Costs to fix during Source Code review: Zero ($) Set rs = cn. Execute(“Select * from Users where UserID = ‘” & request.form(“txtuserid”) & “’ and password = ‘” & request.form(“txtpassword”)”’”

140. Microsoft Threat Modeling via STRIDE and DREAD

141. Threat Risk Modeling Risk Assessment methodology developed by Microsoft which is quickly gaining prominence Aims to identify any security issues in a system before it is operational Think like an attacker The principal idea behind threat modeling is that you cannot build secure systems unless you understand your threats. © Toronto Area Security Klatch 200 7

142. Threat Risk Modeling Used primarily for web applications but can be applied to all systems Allows you to apply a structured approach to system security and to address the top threats that have the greatest risk Threat Modeling listed amongst the most- wanted security skills of 2007 (and beyond) ( www.csoonline.com ) © Toronto Area Security Klatch 200 7

143. Steps in Threat Modeling Identify Assets 1 Create an architecture overview 2 Decompose the application 3 Identify the threats (STRIDE) 4 Document the threats 5 Rate the threats (DREAD) 6

144. Threat Risk Modeling The output is a list of rated threats. The threat model helps you to focus on the most potent threats to the system. © Toronto Area Security Klatch 200 7 System Threat # 1 Threat # 2 Threat # 3 Threat # n

145. Step 1: Identify Assets Build a list of assets that require protection, including: Confidential data, such as customer databases Web pages System availability Anything else that, if compromised, would prevent correct operation of your application

146. Step 2: Create An Architecture Overview Identify what the application does Identify the technologies Create an application architecture diagram NTFS Permissions (Authentication) File Authorization URL Authorization .NET Roles (Authentication) User-Defined Role (Authentication) SSL (Privacy/Integrity) Trust Boundary Alice Mary Bob IIS Anonymous Authentication Forms Authentication IPSec (Private/Integrity) Trust Boundary ASPNET (Process Identity) Microsoft ASP.NET Microsoft Windows r Authentication Microsoft SQL Server™

147. Step 3: Decompose the Application Break down the application and understand the logic behind it Examine interactions between different modules Use DFD or UML diagrams

148. Step 4: Identify the threats In this step, threats that might compromise the system are identified through meetings/brainstorming sessions with project team members Microsoft uses the STRIDE methodology for identifying known threats

149. STRIDE Methodology for Threat Identification A methodology for identifying and categorizing threats “ Business” oriented – easier for non-technical persons to relate to © Toronto Area Security Klatch 200 7

150. Threat Identif./Categorization via STRIDE © Toronto Area Security Klatch 200 7 Types of threats Examples S poofing Forging e-mail messages Replaying authentication packets T ampering Altering data during transmission Changing data in files R epudiation Deleting a critical file and deny it Purchasing a product and deny it I nformation disclosure Exposing information in error messages Exposing code on Web sites D enial of service Flooding a network with SYN packets Flooding a network with forged ICMP packets E levation of privilege Exploiting buffer overruns to gain system privileges Obtaining administrator privileges illegitimately

151. Step 5: Document the Threats Document the threats identified using a standard template: Leave Risk blank (for now) Threat Description Injection of SQL Commands Threat target SQL Server Backend database Risk Attack techniques Attacker appends SQL commands to user name, which is used to form a SQL query Countermeasures Filter all browser input for malicious characters, and use a stored procedure with parameters to access the database

152. Step 6: Rate the Threats Now that threats have been identified, they are required to be rated We can use the standard formula: Risk = Probability * Damage Potential Problem is that above formula is usually too project simplistic for team members to agree on

153. Risk Ratings using DREAD Methodology Microsoft Uses the DREAD model to generate risk ratings: D amage potential : How great is the damage if this threat occurs R eproducibility : How easy is it to reproduce the attack ? E xploitability : How easy is to launch the attack ? A ffected users : How many users are affected ? D iscoverability : How easy is it locate this threat ? Each of the above can be ranked as High (1), Medium (2), Low (3) and added to get the total risk rating © Toronto Area Security Klatch 200 7

154. Risk Ratings using DREAD Methodology © Toronto Area Security Klatch 200 7 High (3) Medium (2) Low (1) D Damage Potential Attacker can completely compromise the system gaining full access Sensitive information might be leaked Leakage of trivial information R Reproducibility Attack can be reproduced every time and does not require some condition Attack can be reproduced only within a specific condition Attack is very difficult to reproduce E Exploitability Novice attacker can use this threat Skills required In-depth knowledge of system required A Affected Users All Users Some users Only specific users D Discoverability Information about this threat is available on the Internet It would take some time before attacker becomes aware of this vulnerability Highly unlikely that users will come across this security flaw

155. Risk Ratings using DREAD Methodology Sample DREAD Risk Rating Threat D R E A D Total Rating Injection of SQL commands 3 3 2 2 2 12 High Leakage of passwords through network monitoring 2 2 2 3 2 11 Medium Stealing of passwords through key loggers 2 3 3 2 3 14 High DREAD Risk Rating 5-7 Low Risk 8-11 Medium Risk 12-15 High Risk

156. Step 6: Rate the threats Threats identified in step 5 can now be rated Threat Description Injection of SQL Commands Threat target SQL Server Backend database Risk High Attack techniques Attacker appends SQL commands to user name, which is used to form a SQL query Countermeasures Filter all browser input for malicious characters, and use a stored procedure with parameters to access the database

157. Threat Risk Modeling Free Threat Modeling tool available from microsoft.com © Toronto Area Security Klatch 200 7

158. Resources

159. Open Web Application Security Project www.owasp.org Web based community dedicated to web application security Most popular documents are OWASP Guide and OWASP Top 10 vulnerabilities

160. OWASP Top 10 No. Vulnerability A1 Cross Site Scripting (XSS) A2 Injection Flaws A3 Malicious File Execution A4 Insecure Direct Object Reference A5 Cross Site Request Forgery (CSRF) A6 Information Leakage and Improper Error Handling A7 Broken Authentication and Session Management A8 Insecure Cryptographic Storage A9 Insecure Communications A10 Failure to restrict URL access

161. Hacking

162. Google Search Engine that drives the world This amazing functionality can be used against an organization to gather information Primary concern is with Information LEAKAGE Used properly Google can be utilized as a security scanner

163. Google Hacking Google syntax can be leveraged to run specific searches against an organization Can be used to find Files containing password information Web Email Access Database files Remote Access Servers Web Servers such as IIS , Apache Servers etc. Security Reports Web Application vulnerabilities (SQL Injection, XSS etc.)

164. Google Hacking Site: limits the search to a website of particular interest Example : site:microsoft.com

165. Google Hacking InTitle: Searches within the title of a page Example intitle:”Test Page for Apache”

166. Google Hacking intitle:”Welcome to Outlook Web Access”

167. Google Hacking intitle:”Welcome to IIS”

168. Google Hacking intitle:”Nessus Scan Report” “This file was generated by Nessus”

169. Google Hacking Filetype: Limits search to particular file extensions Example: “filetype:xls”

170. Google Hacking Filetype:xls UserID | Email

171. Google Hacking inurl : Google searches within the url of a document Example: inurl:5800 &quot;VNC Desktop&quot;

172. Google Hacking intitle:&quot;Remote Desktop Web Connection&quot; inurl:tsweb

173. How to protect yourself Have a policy in your organization regarding which information can be put on the web Regularly run Google searches against your own organization’s web presence Remove default administrative web pages Use “ robots.txt ” file

174. Google Hacking Database http://johnny.ihackstuff.com/ghdb.php The Google Hacking Database (GHDB) is a complete collection of all known Google hacks contributed by the Google hacking community to the public. GHDB is one of the best resources available on the Internet for search engine hacking.

175. FoundStone's SiteDigger Tool Automated tool for running Google searches against your organization Requires a Google License Key Provides an extensive report of the target website, showing possible information leakage via Google Hacking.

176. Conclusion

177. Conclusion Two things have changed in the last few years Attackers are no longer targeting organizations for pride and ego but for profit Software has become the primary target of exploitation Firwalls, SSL, Passwords etc. amount to nothing if your web application is insecure

178. Conclusion “2007 dollar figure of the actual cost of insecure software to the U.S. to be at least $180 billion per year”

179. Conclusion Never trust anything coming from the browser Be on good terms with your developers Integrate security within your software lifecycle Security training for QA, Developers And lastly …

180. Don’t become this guy !

181. Thanks for listening !