1 / 21

COMP3371 Cyber Security Week 10

COMP3371 Cyber Security Week 10. Richard Henson University of Worcester December 2017. Learning Objectives…. Explain the different ways external hackers can find their way into an organisation via its website

abodin
Télécharger la présentation

COMP3371 Cyber Security Week 10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. COMP3371Cyber SecurityWeek 10 Richard Henson University of Worcester December2017

  2. Learning Objectives… • Explain the different ways external hackers can find their way into an organisation via its website • Use vulnerability testing software within the law to check access to the organisation’s network (and information about it!) from outside • Explain the difference between vulnerability scanning and penetration testing and advise on appropriateness of each

  3. Software and System Vulnerabilities • As previously stated: • unpatched software is manna from heaven for hackers • Anyone can assess fairly quickly whether operating systems, applications, or development environments are up-to-date • In this final session, we’ll look a little closer at how “ethical hacking” can help keep organisations free of exploitable software

  4. Software Vulnerabilities • Open source software is likely to be more vulnerable (because it is free!) • software without an obligation to provide support is potentially dangerous • Commercial producers have an obligation to provide support in conjunction with the licensing agreement!

  5. Software Vendors… and Quality • Testing… is an important factor • Mitre (US government funded organisation) focuses on testing applications and operating systems • vulnerability in software reported to software vendors • one month to fix and tell customers • then go public!

  6. Advantages/Disadvantages of Mitre approach • Advantages: • users will become more aware of vulnerabilities • commercial software will get better! • Disadvantages: • assumes that vendors will act promptly • assumes that customers will patch • going public also alerts hackers

  7. Use of a Quality Standard to justify spending on security • Whatever the business… • any new work will have a cost • cost needs to be qualified • More cost means less profit… • what is the ROI of achieving a high level of information security • At least with information assurance (assuming they get certified) there is a positive outcome…

  8. Potential Financial Benefits of Information Assurance • Need to be sold to senior mgt… • less risk of losing valuable (even strategically important…) data • less likely to get embarrassing leaks, which could even get to the media (!) • less likely to fall foul of the law (!) • an ever growing set of examples of businesses who have done both of the above • evidence that they lost customers and share price dropped…

  9. Testing Software • Final version tested for vulnerabilities… • with typical input data - known as “run-time” or “black box” testing • according to coding expectations (e.g. branching and looping) - known as white box testing • If all tests passed… • software ready for rollout? • could be “risk assessed” first?

  10. Further Testing for Websites • Two more types of testing… • historically more emphasis on “accessibility” of content (W3C) • website had to be available to all users to meet requirements of 2004 Legislation • testing tended to focus on this aspect • only later did testing for “security” become mainstream… • still some confusion • need to test for both!!!

  11. OWASP (Open Web Applications Security Project) • Core purpose: • “Be the thriving global community that drives visibility and evolution in the safety and security of the world’s software.”

  12. OWASP’s top 3 vulnerabilities • A1 Injection • Through: SQL, OS, XXE, LDAP • Untrusted data is sent to an interpreter as part of a command or query. • Hostile data can trick the interpreter into • executing unintended commands • accessing data without proper authorization. • A2 Broken Authentication • Authentication/session management implemented incorrectly • Allows attackers to • compromise passwords, keys, or session tokens, • or to exploit other implementation flaws to assume other users’ identities • A3 Sensitive Data Exposure • XSS allows attackers to execute scripts in the victim’s browser • which can hijack user sessions, deface web sites, • or redirect the user to malicious sites. • XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, • or updates an existing web page with user supplied data • using a browser API that can create JavaScript.

  13. OWASP: Next 3 • A4 XML External Entities (XXE) • Restrictions on what authenticated users allowed to do not properly enforced. • Attackers exploit these flaws to access unauthorized functionality and/or data, (e.g. access other users accounts, view sensitive files, modify other users data, change access rights, etc.) • A5 Broken Access Control • Secure configuration should be defined/deployed for the application, frameworks, application server, web server, database server, platform, etc. • Secure settings should be defined, implemented & maintained (defaults often insecure). Software should be kept up to date • A6 Security Misconfiguration • Many web applications and APIs do not properly protect sensitive (financial, healthcare, PII) data • such data stolen/modified to conduct credit card fraud, identity theft, or other crimes. Sensitive data needs encryption at rest or in transit, as well as special precautions when exchanged with the browser.

  14. OWASP: Next 2 • A7 Cross-Site Scripting (XSS) • Many applications/APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks • attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, even blocking exploit attempts • application owners need to deploy patches quickly to protect against attacks • A8 Insecure Deserialization • A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request - including the victim’s session cookie & any other automatically included authentication information - to a vulnerable web application • Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate

  15. OWASP: Final 2 • A9 Using Components with Known Vulnerabilities • components, such as libraries, frameworks, and other software modules, run with the same privileges as the application • vulnerable component exploited.. can result in serious data loss , even server takeover • applications and APIs using components with known vulnerabilities may undermine application defences and enable various attacks and impacts • A10 Insufficient_Logging & Monitoring • Modern applications may have rich client applications and APIs • e.g. JavaScript & mobile apps • These connect to an API (SOAP/XML, REST/JSON, RPC, GWT, etc.) • Apps often unprotected and contain numerous vulnerabilities.

  16. Vulnerability Testing Tools • Many Website tools… • many free to download (!?) • best to use one recommended by a professional (!) • OWASP (Open Web Applications Security Project) • Worldwide… make security “visible” • Vulnerability testing tool called ZAP

  17. OWASP/ZAP • ZAP has evolved over many years, thanks to the efforts of enthusiastic experts wishing to put their expertise to good use • mostly used for passive scanning but also active components • All that is needed is the URL of the website… • results of scan need careful interpretation

  18. Using ZAP • Open source & versions for all major platforms • needs Java Environment to run • described as a “man-in-the-middle proxy” • Stands between the tester’s browser and the web application • can intercept and inspect messages sent between browser and web application.. • modify the contents if needed • forward packets on to the destination

  19. Output from ZAP • I tried it on a site… four vulnerabilities detected: • Prone to “clickjacking” • Solution: use the X-frames-options http header • AUTOCOMPLETE attribute not disabled • ngood practice for password fields • Could allow proxies to cache content • Cache-control and pragma http header not set correctly • Prone to XXS • Protection not fully engaged

  20. Now over to you… • ZAP may not run on university machines • If not, download and try on your own machine • The application you will test is quite old, but demonstrates various principles of (not…) secure web applications • it is harmless but modern browsers offer protection against all unsigned .exe files

  21. That’s all for 2017! Have a Great Christmas! See you in the New Year 

More Related