Download as PDF, PPTX
Uploaded byTriNimbus
Web App Security Presentation by Ryan Holland - 05-31-2017
The document discusses web application security, highlighting the increasing threats and vulnerabilities faced by web apps, particularly in cloud environments. It emphasizes the need for better coding practices, continuous monitoring, and a structured security management approach, including patch management and access control strategies. Additionally, it outlines various hacking methodologies and advocates for integrating security measures throughout the software development lifecycle.
In this document
Powered by AI
Introduction to securing web applications presented by Ryan Holland, Sr. Director, Cloud Architecture.
Data on threat distribution in cloud and brick-and-mortar environments; highlights types of attacks: application, brute force, reconnaissance.
Web apps are increasingly targeted; attacks have risen by 300% since 2014.
Insights from Alert Logic analysis on breaking down web application attacks.
Specific vulnerability related to SQL injection over the last 60 days.
Risks in web app security due to complexity, changes, third-party tools, and lack of expertise.
Identifies layers of web application and its critical components needing protection.
Details of CVE-1999-0278 vulnerability affecting IIS, illustrating security risks.
Discusses how web applications become vulnerable, emphasizing risk factors.
Highlights how unsanitized data and lack of input control can lead to vulnerabilities.
Risks from outdated or inadequate code management and undiscovered system vulnerabilities.
Challenges in keeping content management systems secure, including unsupported plugins.
Advocates for integrating security into the software development life cycle and ensuring regular code reviews.
Introduction to methods utilized by hackers to gather information on targets.
Description of various reconnaissance techniques including website crawling and forum usage.
Manual and automated techniques for gathering critical information from target websites.
Explains Google Dorking as a method for finding vulnerabilities using search engine queries.
Illustrates how complexities arise in utilizing Google Dorking for vulnerability identification.
Importance of vendor response to vulnerabilities reported by users in open forums.
Discusses the role of open forums in sharing vulnerability information and the varying vendor responses.
Details examples like Exploit Database and Full Disclosure that facilitate information sharing.
Information often posted includes vulnerability details and impacted platforms.
Describes the Dark Web, its encryption, restricted access, and the tools used within.
Additional insights and examples of activity on the Dark Web.
Introduction to various methodologies hackers employ during attacks.
Differentiates between opportunistic and targeted attacks in cybersecurity.
Describes techniques hackers use to exploit available vulnerabilities at low cost.
Detailed tactics employed in targeted attacks including social engineering and privilege escalation.
Details on how vulnerabilities in web apps can lead to broader system compromises.
Techniques like code analysis and session hijacking that hackers use to gain access.
Explains the methods attackers utilize to obtain sensitive credential information.
Covers sophisticated methods used by hackers in session hijacking attacks.
Introduction to strategies for remediating web application security vulnerabilities.
Importance of establishing clear access policies and auditing processes.
Emphasizes the need to comprehend the security models of service providers.
Outlines a comprehensive approach to monitoring for malicious activity and compliance.
Discusses the significance of a structured patch management routine.
Advises on secure coding practices and continuous code scanning.
Lays out a DevSecOps release pipeline for ongoing vulnerability assessment during deployment.
Describes how to efficiently implement scanning within continuous integration workflows.
Highlights important resources for threat intelligence and vulnerability awareness.
Closing remarks to conclude the presentation.
More Related Content
Similar to Web App Security Presentation by Ryan Holland - 05-31-2017
![Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day3-cfd-251120170304-ddef8112-thumbnail.jpg?width=640&height=640&fit=bounds)
Web App Security Presentation by Ryan Holland - 05-31-2017
- 1. WEB APPLICATION SECURITY: PROTECTINGYOUR WEB APPLICATION Ryan Holland Sr. Director, Cloud Architecture
- 2. Threats by CustomerEnvironment Source: Alert Logic 2015 Customer Data 48% 23% 21% 2% 6% CLOUD ATTACKS APPLICATION ATTACK BRUTE FORCE RECON SUSPICIOUS ACTIVITY TROJAN ACTIVITY 25% 47% 10% 11% 7% Brick and Mortar ATTACKS APPLICATION ATTACK BRUTE FORCE RECON SUSPICIOUS ACTIVITY TROJAN ACTIVITY
- 3. Web Apps –Prime Target for Attackers Source: Cloud Security Spotlight Report 2016 Source: VDBIR 2016 UP 300% SINCE 2014
- 4. Alert Logic data– Breaking down web app attacks Source: Alert Logic ActiveWatch analysis Aug 2015 through Dec 2016
- 5. SQL Injection Last60 Days
- 6. Vulnerabilities + Change + Shortage Complexityof defending web applications and workloads Risks are moving up the stack 1. Wide range of attacks at every layer of the stack 2. Rapidly changing codebase can introduces unknown vulnerabilities 3. Long tail of exposures inherited from 3rd party development tools 4. Extreme shortage of cloud and application security expertise Web App Attacks OWASP Top 10 Platform / Library Attacks System / Network Attacks Perimeter & end-point security tools fail to protect cloud attack surface Web Apps Server-side Apps App Frameworks Dev Platforms Server OS Hypervisor Databases Networking Cloud Management
- 7. Web Application Security WebApps Server-side Apps App Frameworks Dev Platforms Server OS Hypervisor Databases Networking Cloud Management
- 8. Web Application VulnerabilityExample CVE-1999-0278 – in IIS, remote attackers can obtain source code for ASP files by appending “::$DATA” to the URL Patch MS98-003 Web Apps Server-side Apps App Frameworks Dev Platforms Server OS Hypervisor Databases Networking Cloud Management
- 9. HOW WEB APPLICATION BECOMEVULNERABLE
- 10. Poor Coding Practices •Unsanitized Data - User controlled input - Web forms - URL query exposure • Whitelisting - Control expected user input - Accept known, expected data • Meta-Character Sanitization - Quotes break up a query - Names with quotes should be the exception Web Apps Server-side Apps App Frameworks Dev Platforms Server OS Hypervisor Databases Networking Cloud Management
- 11. Old Reliable Codeand Processes • Lack of Code Cleanup - Failed old code - Decommissioned backend systems - Account credentials - Backup systems - Discovery of application topology (API and static links) - Unnecessary comments and notes
- 12. Unpatched and UnsupportedCode • CMS versions are updated - Vulnerable plug-ins and themes remain o Still function o No error codes o CMS application doesn’t check • TimThumb Word Press Plug-in - Library used to resize larger images - 39 million operational - Author announced end of support - Plug-in hacked
- 13. Lack of SecurityOversight • Security is not longer just advisory • Inject Security into the SDLC • Inject Requirements • Make sure the Technologies are Secure • Automatically and Manually review all code during multiple points throughout the development process • Test, Test, Test • Continuous monitoring and scanning
- 14.
- 15. Hacker Recon Methods CrawlingTarget Website Mass Vulnerability Crawl Open Forums Dark Web Web Apps Server-side Apps App Frameworks Dev Platforms Server OS Hypervisor Databases Networking Cloud Management
- 16. Crawling Target Website •Manual - Browse the website as a normal user - Gather email addresses, related domains and domain info - Web application code language o Revision o Plug-ins - Web server OS - User input pages - Directory structure - Backend systems • Software tools - Find hidden forms, software version, js files, links and comments
- 17. Mass Vulnerability Crawl- Example • Google Dorking – (aka Google hacking) Uses the search engine to find difficult information using complex, detailed search queries - Plug in search string to find vulnerable websites - Some have preset search strings - Search results are dynamic - Timing is everything o Target system could be patched o Other hackers got there first
- 18. Google Dork –Example
- 19. Open Forums • Vulnerabilitiesreported to vendors - Vendors should o Acknowledge vulnerability o Provide timeline to fix o Announce vulnerability to the public o Provide fix/patch or work-around o Within a reasonable timeframe - Some Vendors o Delay response to reports o Don’t provide a patch o Announce vulnerability only to customers o Bury patches with other “upgrades”
- 20. Open Forums • Informationsharing - Researchers post vulnerabilities o Lack of response from the vendor o Bypass vendor completely - Public service to Internet community o On-going debate • Bypass the vendors and post vulnerabilities • Involve the vendor first o What is a reasonable amount of time • Some say it should be 24 hours or less • Some agree to wait 4-6 weeks • Others somewhere in between Open forums facilitate vendor due diligence
- 21. Open Forums -Examples • Exploit Database - www.exploit-db.com - A non-profit project that provides a public service to share information about vulnerabilities and is run by Offensive Security • Full Disclosure - http://seclists.org/fulldisclosure/ - A public, vendor-neutral forum of vulnerabilities, exploitation techniques and other events of interest to the community • Cryptome - https://cryptome.org/ - Collects information about freedom of expression, privacy, cryptology, dual-use technologies, national security, intelligence, and government secrecy
- 22. Open Forums -Example • Vulnerability details - Date reported - Type of vulnerability - Platform impacted - Author (not shown) - Verification (time permitting) - Link to infected application (some)
- 23. Dark Web • Encryptednetwork • Restricted access between Tor servers and clients • Collection of DBs and communication channels • Hidden from conventional search engines • Shares some features with Open Forums • Tor browser required • More advanced resources and tools
- 24. Dark Web -Example
- 25.
- 26. Attack Methodology • Attackof opportunity - Hacker finds vulnerability within skillset - Target system and organization irrelevant • Targeted attack - Specific to people or organization - System resources • Low cost of entry - Open list of vulnerabilities - Targets easy to find - Hacker’s skill-set varies
- 27. Attacks of Opportunity •Vulnerability Database Monitoring • Block Network Vulnerability Scanning • Google Dorking • Shodan • Application Vulnerability Scan
- 28. Targeted Attacks • ScanningIP Internet Assets • Application/Network Vulnerability Scan • Careers Page • Research Technologies • Social Media Profiling • Phishing Email • Escalate Privileges • Maintain Access • Exfiltration of Data
- 29. FROM WEB APPSTO PRIVILEGED ACCESS
- 30. From Web Appsto Privileged Access • How hacking a web app can lead to system compromise - Code analysis o Review of code to reveal unintended system information - System scanning o Other software could have vulnerabilities - Session Hijacking o Exploiting a current, valid session - Social Engineering o Deception used to manipulate behavior
- 31. From Web Appsto Privileged Access • Code analysis - Account information o Usernames and passwords o Plain text or hashed - Software tools o Web search o Scan to identify • Usernames & passwords o Brute force to crack encryption o Throttle tools to avoid detection o Offline may be an option
- 32. From Web Appsto Privileged Access • Session Hijacking - Obfuscated code o Embedded in images o Mouse-over techniques - Proxy replay - Malicious binary - Session cookies - Java script injection - Cross-site scripting - Routine system maintenance - Bind shell
- 33.
- 34. Create Access ManagementPolicies • Identify data infrastructure that requires access • Define roles and responsibilities • Simplify access controls • Key Management System (KMS) • Continually audit access • Start with a least privilege access model
- 35. Understand Your ServiceProviders Security Model
- 36. Security Management andMonitoring Strategy • Monitoring for malicious activity • Scanning Services • Forensic investigations • Compliance needs • System performance • All sources of log data is collected • CloudTrail – Use it, Love it. • WAF • Correlation logic • IAM behavior • IDS Network traffic • FIM Logs • Focused security research • Security content creation • Review process • Live monitoring
- 37. Adopt a PatchManagement Approach • Constantly scan all production systems • Compare reported vulnerabilities to production infrastructure • Classify the risk based on vulnerability and likelihood • Test patches before you release into production • Setup a regular patching schedule • Keep informed, follow bugtraqer • AMI and Golden Images • Reference Architecture, Formation Templates
- 38. Secure Your Code •Test inputs that are open to the Internet • Add delays to your code to confuse bots • Use encryption when you can • Test libraries • Scan plugins • Scan your code after every update • Limit privileges • DevSecOps
- 39. DevSecOps Release PipelineDesign • Cloud Insight is a purpose built SaaS platform providing vulnerability assessment for AWS customers. • Jinkins and AWS services are used for deployment pipeline. • Micro-services architecture with several development teams. • Multiple deployments a week. • Fully automated deployment pipeline. • Deployment pipeline consists of 4 environments • Development • Integration • Staging • Production • Requirement that vulnerabilities are identified and remediated before changes push to production. • Cloud Insight will scan all instances running in Integration every 24 hours.
- 40. How to ImplementedScanning in the Pipeline • Scanning a large number of instances takes time –want to avoid slowing down releases. • Workflow for Staging environment queries vulnerability data from scans in Integration. • Vulnerabilities tracked by AMI, not instance IDs. • Scan reports are attached to RFCs and stored in S3. • Any vulnerability of CVSS > 4.0 triggers a rollback. - Scan report with remediation steps are attached to the report
- 41. Follow our Research& Stay Informed on the Latest Vulnerabilities Blog https://www.alertlogtic.com/resources/blog Newsletter https://www.alertlogic.com/weekly-threat-report/ Cloud Security Report https://www.alertlogic.com/resources/cloud-security-report/ Zero Day Magazine https://www.alertlogic.com/zerodaymagazine/ Twitter @AlertLogic Websites to follow • http://www.securityfocus.com • http://www.exploit-db.com • http://seclists.org/fulldisclosure/ • http://www.securitybloggersnetwork.com/ • http://cve.mitre.org/ • http://nvd.nist.gov/
- 42.