HTML5 – Hazards and Defense – Podcast with Brakeing Down Security

Part 1 -  2015-039: Hazards of HTML5

Shreeraj Shah (@shreeraj on Twitter) came on this week to give us a run-down of some of the issues with HTML5? How can a new standard actually be worse than something like Flash? And why would a standard not address existing OWASP issues, and even create new issues, like the ability of a browser to have a database inside of it managing everything?

This week we discuss HTML5 history, some of the pitfalls, and discuss some of the new technologies found in HTML5 that will create more headaches for agents of infosec.

Listen the Podcast over HERE

Part 2 -  2015-040; Defending against HTML 5 vulnerabilities

Last week, we discussed with Shreeraj Shah about HTML5, how it came into being and the fact that instead of solving OWASP issues, it introduces new and wonderful vulnerabilities, like exploiting locally stored web site info using XSS techniques, and doing SQLI on the new browser WebSQL.
So this week, it's all about defensive techniques that you can use to educate your developers against making mistakes that could get your company's web application on the front page of the news paper.

Listen the Podcast over HERE

You can find various articles on this topic and issues covered during the session over here.

1. Next Generation Application Architecture & HTML5
2. HTML5 features in a nutshell
3. HTML5/Browser Evolution and Threats
4. Cross Origin Resource Sharing Policy and its impact
5. CSRF and Cross Domain Response Extraction in Era of CORS
6. WebSocket Security - Protecting streams Over HTTP
7. Attack Vectors and Threats for HTML5 Storage (note)
8. Talks on HTML5 Security (HITB and AppSecUSA 2012)
9. XSS & CSRF with HTML5 - Attack, Exploit and Defense
10. File System API with HTML5 – Juice for XSS
11. CSRF with upload – XHR-L2, HTML5 and Cookie replay
12. Blind WebSQL and Storage extraction for HTML5 Apps
13. Cross Origin Resource Jacking (CORJacking) - DOM based attack vector
14. Top 10 HTML5 Threats & Attack Vectors

Also, at OWASP we are maintaining HTML5 cheatsheet which you can find it over.

HTML5 OWASP cheat Sheet

Enjoy!

Authentication and Authorization Security Controls – Code Analysis

Authentication

Applications are running on the server and usually serving browsers. Application authentication is form based and done over HTTP. There are several layers involved in the authentication process and each layer should have their own security protections. There are several different authentication mechanism available on application like NTLM, Basic, Digest, HTML Form based, LDAP, Certificate based etc. Authentication is has two aspects in web based application one is authenticating user and second is making a tunnel or channel for authenticated user since HTTP itself is stateless protocol. Various different authentication controls help in protecting application and if any of the control is missing or poorly written then it opens up severe vulnerability in application. Here is a list of possible issues or vulnerabilities

1.) Authentication disclosing sensitive information
2.) Not having auditing on the authentication
3.) No user lockdown policy in place
4.) Authentication bypass (SQL / LDAP interface)
5.) Password strength is poor
6.) No deployment of CAPTCHA or similar identification product
7.) Credential are not securely transmitted
8.) Credential are stored on client side which can be retrieved
9.) Authentication token or cookies are not well crafted
10.) Single Sign On (SSO) can be abused
11.) Deliberated backdoors are created
12.) Hidden fields and information exposure

Authentication controls are part of application code and it is imperative to analyze full mechanism in detail. This layer of code can help in identifying possible loopholes. Authentication is very critical for sensitive and transaction based sites like banking, trading or mailing system. An attacker can bypass authentication and can take hold of full session, it gets opportunity to advance hacking from there. Over years we have seen popular attack vectors as below

1.) Brutefocing
2.) Cookie theft and replay
3.) Authentication injections with SQL/LDAP
4.) Network eavesdropping and malicious codes
5.) Dictionary attacks
6.) Exploiting backdoors
7.) Hidden data manipulation
8.) Local store and information theft

Above attack vectors can help in exploiting the application and these attacks are easy to carry out using different frameworks. Source code can be written in the most secure fashion to protect against above attacks.

Authorization

Once user gets authenticated next thing is to maintain authorization through out the application. Authorization on the application get maintained using proper access control lists (ACLs). Application runs on HTTP and being a stateless protocol, session tokens are required to maintain authorization. There are several issues which can make entire application weak with authorization perspective and that can lead to exploitable security vulnerability. Here is possible weak area in the application for authorization,

1.) Session tokens are insecure
2.) Weak authorization mechanism
3.) Client side tampering and manipulation possible
4.) Possible data and SQL injections
5.) Access to system level bypass
6.) Single place authorization bypass
7.) URL forcing and manipulation
8.) Guessable resources and access
9.) Role-based bypass exploitation and weakness

Above weakness opens up several different set of vulnerabilities. These vulnerabilities can give access to various resources and opens up larger attack surface. Attacker or hacker can launch various attacks and exploits against target application. Here are list of popular attack vectors,

1.) Elevation of privilege
2.) Confidential data leakage
3.) Data tampering
4.) Session hijacking
5.) Session token exploitation
6.) Authorization injections
7.) URL bruteforcing
8.) Clients side reverse engineering and exploits

Above attacks are very popular against applications with respect to authorization. One needs to analyze logic in detail to detect authorization based vulnerabilities.