Your SlideShare is downloading. ×
Web Application Security
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Web Application Security

48,555
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
48,555
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
635
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 09-06-09 class-a SQLRecon
  • Transcript

    • 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
    • 27.
    • 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.
    • 45.  
    • 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
    • 53.  
    • 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
    • 71.  
    • 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
    • 77.  
    • 78.  
    • 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
    • 102.
    • 103.
    • 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 !