Downloaded 37 times
More Related Content
Similar to Web Application Security
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Web Application Security
- 1. Web Application SecurityPresented by: Colin English Zerflow
- 2. Session Overview WebApplication Security The Myth and The Facts Examples of Web Application Vulnerabilities Web Application Auditing & Testing
- 3. The Myth “Our site is safe”: We have firewalls in place We encrypt our data We have a privacy policy
- 4. Recent News QwestGlitch exposes customer data - Securityfocus.com May 23, 2002 Hackers attack eBay accounts — ZDNet News Mar 25,2002 NY Times Internal Network Hacked — Internet.com, Feb 27, 2002 Sites Revealed Passwords For Thousands Of Ameritech Users — NewsBytes Feb 22,2002 Software bug bites U.S. Military — BBC, Mar 18,2003 NASA investigating hacker theft of sensitive documents - ComputerWorld Aug 8 ,2002 Glitch at Fidelity Canada exposes customer information — ComputerWorld, May 30, 2002 Hacker Accesses 2.2 Million Credit Cards - CNN, Feb 18,2003 Gov’t Web Sites open to Hack Attacks CBS News, Jan 25, 2003 Vivendi Says Online Shareholder Voting Hacked — NewsBytes, Apr 29, 2002 Hackers steal students soc.sec. numbers — ABCNews, Mar 6,2003 FTD.com hole leaks personal information — CNet, Feb 13, 2003 Security worries hold back UK online tax returns — TheRegister, Jan 29,2003
- 5. Pressures on theApplication Lifecycle Time-to-Market Bringing new applications to market quickly Complexity is Growing Increasing application lifecycle complexity Increasing Business Risks Driven by Security Defects Hacker activity increasing Government scrutiny and regulation increasing Liability precedents for security defects Costs Escalate Dramatically the longer you wait to Find and Fix Bad software costs the economy $59.5 billion a year- cost of breakdowns and repairs (Nat. Institute of Standards & Technology, May 2002) Financial Services Application
- 6. Cyber crime onthe Rise On average, there are 5 to 15 defects in every 1,000 lines of code US Dept. of Defense and the Software Engineering Institute It takes 75 minutes on average to track down one defect. Fixing one of these defects takes 2 to 9 hours each 5 Year Pentagon Study A company with 1,000 servers can spend $300,000 to test & deploy a patch; most companies deploy several patches a week Gartner Group MS $100 million Trustworthy-Computing initiative: improve SW security & reduce number of software updates and security bulletins issued
- 7. Application Security DefectsFrequent 3 out of 4 business websites are vulnerable to attack (Gartner) Pervasive 75% of hacks occur at the Application level (Gartner) Undetected QA testing tools not designed to detect security defects in applications Manual patching - reactive, time consuming and expensive Dangerous When exploited, security defects destroy company value and customer trust 167 Audits conducted – 98% vulnerable: all had firewalls and encryption solutions in place…
- 8. Cost Increases Laterin the Lifecycle Security is Addressed Cost to Fix dramatically increases the longer you wait to test
- 9. Web Application VulnerabilitiesWithout any protection, holes and backdoors exist at every layer waiting to be exploited Web Server User Interface Code Frontend Application Backend Application Database Data Invalid Data can exploit weakness in the application acting as escape holes resulting in access to unauthorized accounts, O/S network, sensitive data and may result in an application denial of service Valid Input HTML/HTTP Browser Invalid Input HTML/HTTP
- 10. Types of ApplicationHacks Through a browser, a hacker can use the smallest bug or backdoor to change, or pervert, the intent of the application Application Attack Types Negative Outcome Examples Form field: collect data Buffer overflow Crash servers/close business Online shopping Hidden fields eShoplifting Text Field: collect data Cross Site scripting eHijacking - Get account info Front end Apps 3 rd Party Misconfiquration Admin access Backend Apps Stealth Commanding Site defacement Sloppy code Backdoors/Debug options Download proprietary database Customer account Cookie poisoning Identity theft/illegal transactions Database Parameter Tampering/SQL injection Fraud Web Server Published Vulnerabilities Crash site Web Server Forceful Browsing Access sensitive data
- 11. 10 Types ofAttacks: Development Lifecycle APP. BUFFER OVERFLOW COOKIE POISONING CROSS SITE SCRIPTING HIDDEN MANIPULATION STEALTH COMMANDING 3 RD PARTY MISCONFIG. KNOWN VULNERABILITIES PARAMETER TAMPERING BACKDOORS & DEBUG OPT. FORCEFUL BROWSING Development Operations 3 rd party SW
- 12. Hidden Field ManipulationVulnerability explanation : The application sends data to the client using a hidden field in a form. Modifying the hidden field damages the data returning to the web application Why Hidden Field Manipulation : Passing hidden fields is a simple and efficient way to pass information from one part of the application to another (or between two applications) without the use of complex backend systems. As a result of this manipulation : The application acts according to the changed information and not according to the original data
- 13. Hidden Field Manipulation- Example
- 14. Hidden Field Manipulation- Example
- 15. Hidden Field Manipulation- Example
- 16. Hidden Field Manipulation- Example
- 17. Backdoor & Debugoptions Vulnerability explanation : The application has hidden debug options that can be activated by sending a specific parameter or sequence Why Backdoor and Debug options : Leaving debug options in the code enables developers to find and fix bugs faster Developers leave backdoors as a way of guaranteeing their access to the system As a result of this manipulation : Activation of the hidden debug option allows the hacker to have extreme access to the application (usually unlimited).
- 18. Backdoor & Debugoptions - Example
- 19. Backdoor & Debugoptions - Example
- 20. Backdoor & Debugoptions - Example
- 21. Cross Site ScriptingVulnerability explanation : A third party creates a link (or sends an email) and the URL contains a parameter with a script – once the user connects, the site runs this script Why Cross Site Scripting : Many parameters are implanted within the HTML of following responses, while not checking their content for scripts. As a result of this manipulation : “Virtual hijacking” of the session. Any information flowing between the legitimate user and site can be manipulated or transmitted to the evil 3 rd party.
- 22. Press this linkto get to your bank Underlying link: http://www.mybank.com?a=<evil javascript> The JavaScript program collects and sends user names and passwords Enter your login information Cross Site Scripting - Example 1 2 Username Password 3
- 23. Parameter Tampering Vulnerabilityexplanation : Parameters are used to obtain information from the client. This information can be changed in a site’s URL parameter Why Parameter Tampering : Developers focus on the legal values of parameters and how they should be utilized. Little if any attention is given to the incorrect values As a result of this manipulation : The application can perform a function that was not intended by its developer like giving access to customer information
- 24. Parameter Tampering -Example
- 25. Parameter Tampering -Example
- 26. The Missing PieceProtection for the application itself Applications are vulnerable Developers lack tools and know how to build secure applications No amount of QA testing will capture all the security vulnerabilities Systematic failures in the application can be engineered by hackers
- 27. Web Application Hacking- Results
- 28. Auditing & TestingThe process Coverage of relevant business process Full inspection of client side scripts and comments Full inspection of application interfaces Analysis of potential vulnerabilities Testing of potential vulnerabilities Check for installation of known patches The knowledge Complete understanding of the application logic Complete knowledge of application manipulation methods Awareness of all the known patches issues Complete understanding of most secure configuration of all tools
- 29. Auditing – TheProblem Multiple points of people failure Development, QA, Operations, Vendor software, Outsourcing New third party bugs discovered every day site exposed during patch latency Site Complexity many line of codes and application interactions Compressed application development cycle time to market needs will impact development and QA Distributed Knowledge Any single person does not have all the knowledge needed for a full audit.
- 30. What is aViable Solution? VIABLE = Positive Security Model : Assessment : bullet-proof applications before production Application Firewalls : block, log and alert against known/unknown attacks Behavioral/ Policy-based Automatically builds a policy in real time for the site Allows only intended business interactions Maintains intended application behavior e.g., Code Red and Nimda blocked without updates or rules Not Viable = Negative Security Model : Signature/Rules-based – Blocks known attacks based on signatures, heuristics or rules e.g., - need patch installed or signatures written to block Code Red & Nimda
- 31.
- 32. Thank You forYour Attention
Editor's Notes
- #5 Worldwide problem
- #6 STEVE ORRIN: We all know that there are pressures on the application lifecycle. Let’s review the facts: Time to market demands are ever increasing – bringing new apps up quickly while not compromising their usability and ‘cool factor’ is imperative. Budgets are tight in today’s economic environment and expenses are closely monitored. Unfortunately, this doesn’t translate into a lessening of the market’s expectation for new applications. At the end of the day, the question facing most development teams is ‘How do we meet the functional specification on time with the resources available?” Application complexity is growing – as applications grow in size complexity is added at every step. Businesses and the market expect new applications to perform, meet the functional spec, deploy quickly – and to be secure. And while the deployment pace speeds up, so does the scale and complexity of the sites the new applications are being deployed on. This increases the number and type of potential points of failure within an application --- any one of which could be the source of an enormous problem for the enterprise. Increasing Business Risks Driven by Security Defects. As more business gets done on the web, the risks posed by security defects in deployed applications are accelerating. Hackers are increasingly active and sophisticated about how they choose and target their victims. Dealing with this threat effectively is not trivial. Growing government scrutiny and regulations, including GLBA and HIPAA. With the increase in the value of information and assets accessible through the Web, governments around the world are creating laws and regulations to protect consumers from online fraud and theft. Compliance to U.S. laws like HIPAA and GLBA are for the first time putting the issue of application security into the CEO’s office and board rooms of the largest enterprises in the world. Failure to comply can come at an enormous cost. And finally, recent court activity relating to liability protection for bad software has added new areas of risk for all businesses. Simply put, it doesn’t look like Caveat Emptor (buyer beware) will be sufficient to protect companies from liability claims and class action lawsuits. Enterprises must take systematic and significant measures to ensure that the applications under their domain do not directly or indirectly lead to harm of the customer or the shareholders. Add to this the fact that cost escalates dramatically the longer you wait to find and fix defects, and it is clear things need to change (NEXT SLIDE)
- #8 STEVE ORRIN: All of this should lead you to demand better application security. But, if you still need more facts, lets review some more data points: Web application attacks are now more frequent. In Q1 2002, Sanctum found serious security defects in applications in 100% of the commercial sites we audited; The attacks are more expensive to recover from. Costs to patch are high, and the cost of a lost reputation is impossible to quantify. The attacks are more pervasive. A F50 Sanctum customer found serious security defects in over 700 of its deployed applications Finally, the attacks are growing more dangerous, and they usually go undetected. When we look closer at what was actually able to be manipulated on the sites we audited, it is quite scary. In 31% of the sites, full control and access was achieved. In 25% of the sites, privacy was breached, and in 3% of the sites, the entire site was able to be deleted. These are serious problems. Next slide
- #9 As you can see from this slide the relative costs associated with waiting to detect and fix defects increases at a staggering rate from one stage to the next. By the time an application has been deployed, a defect found in it can cost as much as 100X as much to fix than if it had been caught during the development and testing process. This is measured in terms of lost time, resources and lost business as the result of the application being down.
- #10 Each layer of the application has its own unique vulnerabilities. A vulnerability fixed at one layer may still be exploited at another layer. An exploit at any layer of the application effects the integrity and behavior for the entire application The bottom line, Code and Content Change every day – and contain bugs and backdoors at every layer (NEXT SLIDE)
- #11 In the Web application layer, we see 10 major types of application level hacks that can occur with varying degreed of impact on the business ranging from site defacement to eHijacking to downloading the company’s proprietary database. For example, in a text field used to collect data from a customer, a hacker may be able to insert a script that eHijacks customer information from the site through a vulnerability called cross site scripting. (HIGHLIGHT A FEW EXAMPLES)
- #13 Also could be an example of 3rd party missconfiguration