Vulnerabilities in modern web applications
- 1. NIYAS N S 14CS246 Vulnerabilities in Modern Web Applications
- 2. Introduction • Trend in modern application design is to move applications into a remote server . • Consistent and quick updates • Application monitoring • and lower requirements on local hardware performance. • eg Office 365, Google Docs etc. • Need good quality of Internet connection • Security
- 3. Contents • Penetration Testing Tools • Web Application Vulnerabilities • Security Recommendations
- 4. Penetration Testing Tools • Higher Security risk of remotely run applications has to be verified, expressed, and minimized. • Main goal - improve the application security via pointing out its security flaws. • There are two basic phases of the testing – Reconnaissance – Application Exploitation
- 5. Reconnaisance Phase • Passive • gather as much info about targeted network. • network itself not accesed. • Active • interact directly with targeted devices. • to identify OS, running services and potential vulnerabilities. • Application Scanning • automatized scanning of web applications. • results can present a general idea of the application • guidance in exploiting existing flaws.
- 6. Passive Phase • Maltego – OSINT (Open Source Intelligence) type. – group of tools using publicly available data. – uses lists of indexes and databases to search for info. • Discover Scripts – OSINT type. – integrates search and scanning utilities in Kali linux OS
- 7. Active Phase • Ettercap – open source multi platform tool for network traffic sniffing – it can capture comm. between two users in a network. – used for gather sensitive informations like password. • Nmap – it can find connected networks end devices,open ports. – it can build a network map – versions of OS, services and running daemons etc
- 8. Application Scanning • Arachni – automatized multi-platform tool for security audits. – using asynchronous HTTP requests, parallel processing of javascript op's and multi-thread scanning. – integreted browser engine , scans web app using advan. tec • OWASP ZAP (Zed Attack Proxy) – Proxy ( comm. capturing) , Scanner (passive,active) Fuzzer (sequ. sends dangerous payload to identify vulnerability), spider(traverse all web pages) ,forced browsing (discover direct access to files stored on the server)
- 9. Web Application Exploitation • SQL Tools – SQLMap • open source tool for testing database part of web app • typical exploitation is SQL injection • in case of succesfull exploitation, the SQLmap can access shell • data can be saved in a file ,if attack is succesfull – NoSQLMap • currently supports only MongoDB, but extensions of NoSQL databases like CouchDB, Redis and Cassandra are planned. • attack itself can take a few minutes , depends on scope.
- 10. Web Application Exploitation • Password Attacks – Hashcat • open source tool supporting many hash algorithms.(SHA,MD) • computation run either on CPU or GPU (parallelized arch) – cudaHashcat for Nvidia – oclHashcat for AMD • hashcat contains following attack modes – straight (classical dictionary attack) – combination (words connected from multiple dictionaries) – brute-force (mask specification allows to omit unused password comb.)
- 11. Web Application Exploitation • Burp Suite • Web Vulnerability Scanner • Proxy (captures and modify communication) • Spider (create map of web application and send forms) • Intruder (realizes attack based on performed analysis) • Repeater (repeatedly modifies HTTP requests &analyze replies) • Sequencer (analyzes the level of security tokens randomness)
- 12. Web Application Exploitation • BeEF (Browser Exploitation Framework) – focused on XSS attacks – BeEF is modular framework – main functionality is hooking process.
- 13. Web Application Vulnerabilities • Cross-Site Scripting (XSS) • Cross-Site Request Forgery (CSRF) • Insecure Direct Object Reference • SQL Injection • Broken Authentication and Session Management
- 14. Cross Site Scripting (XSS) • Malicious code that can change the look and function of a legitimate web application. • More widespread now because of move to more rich Internet applications using dynamic content and JavaScript and the latest AJAX trend. • It can be identified using OWASP ZAP and exploit using BeEF.
- 15. Cross Site Scripting (XSS) • Impact of XSS – Data residing in web page can be sent anywhere in the world. – Facilitates many other types of attacks (CSRF, Session Attacks) – site's behaviour can be hijacked.
- 16. Cross Site Scripting (XSS) • Demo – WebGoat Stored XSS
- 17. Preventing XSS • Escape all user input when it is displayed – Escaping converts the output to harmless html entities • <script> becomes <script> • but still displayed as <script> • Ensure your filter uses a white list approach – Filters based on blacklisting have historically been flawed • E.g. PHP, Ruby on Rails sanitize method – New encoding schemes can easily bypass filters that use a blacklist approach
- 18. Cross Site Request Forgery (CSRF) • A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application. • Occurs when an authenticated user unknowingly initiates a request • XSS facilitates CSRF via “Link Injection”
- 19. Cross Site Request Forgery (CSRF) http://yourbank.com/transfer? to_account=my_account_number&amount=all_of_your_money
- 20. Preventing CSRF • Add a secondary authentication mechanism –Such as an impossible to guess token • Require a confirmation page before executing potentially dangerous actions • Eliminate XSS vulnerabilities • Use POST as your form action and only accept POST requests on the server for sensitive data !
- 21. Insecure Direct Object Reference • A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. • Attackers can manipulate those references to access other objects without authorization. • E.g. /BankAccount.jsp?acct_nmbr=123 –The hacker modifies the parameter to view another users account
- 22. Insecure Direct Object Reference
- 23. Session Attacks Session Fixation Session Hijacking • The hacker predicts a valid session key (usually via phishing) • The hacker masquerades as another user by stealing the users session id (usually via XSS)
- 24. Insecure Direct Object Reference • Demo – Bypass a path based access control scheme
- 25. Preventing Direct Object Reference • Properly validate data! • All input data MUST be validated server side for each request – client side validation is EASILY bypassed • Do not expose internals to the user • Such as IDs (if possible/necessary) • Use an indirect reference map with hard to guess keys (hash) • POST /BankAccount.jsp?acct_nmbr=d83OJdm3 • The server then uses the key to get the real value »Key: d83OJdm3 value: 123
- 26. SQL Injection • SQL injection is a security vulnerability that occurs in the database layer of an application. • Its source is the incorrect escaping of dynamically-generated string literals embedded in SQL statements.
- 27. SQL Injection • Login Example Attack – Text in blue is your SQL code, Text in orange is the hacker input, black text is your application code • Dynamically Build SQL String performing authentication: – “SELECT * FROM users WHERE login = ‘” + userName + “’ and password= ‘” + password + “’”; • Hacker logs in as: ‘ or ‘’ = ‘’; -- – SELECT * FROM users WHERE login = ‘’ or ‘’ = ‘’; --‘ and password=‘’
- 28. SQL Injection • Demo – SQL String Injection
- 29. Preventing SQL Injection • Use Prepared Statements (aka Parameterized Queries) – $id=1234 – “select * from accounts where id = “ + $id vs – “select * from accounts where id =1234” • Escape questionable characters (ticks, --, semi-colon, brackets, etc.) • Validate input – Strong typing • If the id parameter is a number, try parsing it into an integer
- 30. Broken Authentication and Session Management • Account credentials and session tokens are often not properly protected. • Attackers compromise passwords, keys, or authentication tokens to assume other user's identities.
- 31. Authentication Checks • Never store passwords in plaintext – Encrypt or Hash+Salt (preferred) • Architect applications to check every request to see that the authentication data is still valid • Issue a new session token when a change in privilege occurs • If you absolutely must use “remember me” functionality, use a difficult to guess authentication cookie • Authentication data is sent with every request, so protect it
- 32. Preventing Authentication and Session Attacks • Use built in session management! • Use secure randomly generated session keys to make prediction impossible –Don’t expose the user to session ids if possible • Use reasonable session timeouts
- 33. Preventing Authentication and Session Attacks • Demo – Session Fixation