More Related Content
What's hot
What's hot (20)
Similar to Vulnerabilities in modern web applications
Similar to Vulnerabilities in modern web applications (20)
Recently uploaded
Recently uploaded (20)
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