What you'll learn:
- Have a environment to learn web application hacking
- Learn how to use Burp proxy tool
- Identify few basic security vulnerabilities
- Identify bugs within web applications
This course will teach you how to set up Burp Proxy, which is a tool used to find security issues outlined in the OWASP Top 10 (See below for details). This course will also show you to set up my proprietary distribution (WAED) which is loaded with vulnerable web applications. This distribution has around 18 vulnerable applications, and you'll have ample opportunity to learn how to identify web application security issues. This course will get you set up, and my next course will go into details of Web Application pentesting principles. This course should take less than an hour to complete, and once you complete you should already see the power of using these tools whether you're a developer, pentester or a QA analyst.
Web application pentesting is a lucrative field. You can earn anywhere from $100,000 to $120,000 depending upon your skill sets.
Why is Web Application Security very important and Why you should get started?
Given the large amount of financial and other sensitive information that is transmitted over the internet all over the world, it would be a very obvious choice for cyber hackers to focus their efforts. In addition to the increased amount of traffic, the proliferation of insecure web applications also makes web-based hacking attacks even more profitable and attractive.
Breaking into systems is not something new. Since the early 80s skilled hackers and other computer enthusiasts, have used their broad computer knowledge to break into systems with no benefiting intention. However, with the introduction of web applications, the sophistication of hacking activities has greatly increased. Web applications allow visitors access to the most crucial and sensitive information of a website, database server or web server. Developers of these applications dedicate a lot of time on functionality and features but allocate very little time on security. The amount of skills required to carry out such hacking attacks has greatly lessened. Fortunately, there are some ways by which developers can prevent web application hacking.
All web applications vulnerabilities, how hackers exploit them and how to stop and prevent them are covered in the OWASP top ten.
The OWASP Top 10:
The OWASP (open web application security project) is an international organization that is committed to enhancing the security of web applications. OWASP sponsors numerous security related projects including the top 10 project. This project regularly publishes a list of the current top ten web applications security risks (vulnerabilities) worldwide. It provides a detailed report of each vulnerability, gives examples and provides suggestions on how to avoid the risk. The following are its current vulnerabilities and suggestions on how to avoid them.
1. Injection flaws
These flaws occur when a web application sends untrusted data to an interpreter as part of a query or a command. These flaws are often found in LDAP, SQL, NoSQL or Xpath queries, OS commands, SMTP headers, program arguments, XML parsers, etc.
The best way to find out whether your applications are vulnerable to injection flaws is to verify that the use of interpreters is clearly separating untrusted data from the query or command. This involves the use of bind variables in stored procedures and prepared statements and by avoiding dynamic queries altogether. Code analysis tools can assist you trace all data flow through the web application.
Preventing injection flows involves keeping all untrusted data separate from queries and commands by:
- Using a safe API that avoids the use of an interpreter
- Escaping the use of escape-special characters using specific-escape syntax for the interpreter
- Positive (“white list”) input validation.
2. Broken authentication as well as session management
This occurs when application functions that are related to session management and authentication are not implemented correctly. This allows attackers to compromise usernames, passwords, keys and session tokens.
You may be vulnerable to these flaws if your authentication credentials are not properly protected using encryption or hashing, if the credentials can be guessed or if session IDs are exposed in your URL.
Prevent these flaws by:
- Meeting all session management and authentication requirements as defined in the OWASP security verification standards
- Making strong efforts to avoid XSS flaws that can be used by hackers to access session IDs
3. Cross site scripting (XSS)
They occur anytime a web application sends untrusted data to a web browser without escaping or proper validation.
You are vulnerable to these flaws if you don’t ensure all user supplied data and input is escaped, or if you don’t verify the input to be safe through input validation. You can use automated tools to find XSS flaws automatically.
Prevent these flaws by:
- Escape all untrusted data that is based on HTML context (attribute, body, CSS, URL or JavaScript) that your data will be placed into
- Positive input validation is also an option although it is not a complete defense
- Consider auto sanitization libraries such as java-HTML sanitizer project for rich content
4. Insecure direct objects references
They occur when a web developer exposes a reference to any internal implementation object, such as a directory, file or a database key.
The best way to find whether your apps are vulnerable is to verify that all object references have the right defenses. Testing through automated tools may be effective for identifying these flaws.
Protect against the flaw by:
- Using per session or user indirect object references to prevent attackers from targeting unauthorized resources directly.
- Through check access
5. Security mis-configurations
Good application security requires having a secure configuration that is deployed and defined by the application, application server, database server, platform and frameworks.
Automated scanners are very useful for the detection of misconfigurations, missing patches, unnecessary services, use of default account, etc.
Protect against the flaws by establishing the following:
- A repeatable process for following and deploying all software updates in a timely manner to a deployed environment
- An application architecture that is strong enough to provide an effective and secure separation between components
6. Sensitive data exposure
Many applications do not put into place measures to protect sensitive data including tax IDs, credit cards and authentication credentials. The most common vulnerability here is failing to encrypt all sensitive data. Encrypting data doesn’t mean that it is free from weaknesses; it simply means that it is very hard for attackers to exploit such weaknesses, especially on a large scale.
Determine all the sensitive data that require extra protection and act accordingly. Ensure you encrypt all sensitive data in transit and at rest. It is also important to avoid storing such data unnecessarily.
7. Missing function-level access control
Developers must include proper code checks to properly protect applications functions, but they sometimes forget. An attacker is therefore able to access privileged functions by simply changing a parameter to the function or through changing the URL.
These flaws allow an attacker to access administrative functions and other unauthorized functionalities. If such vulnerability becomes public, your reputation will be greatly damaged.
It is important to deny all access by default in order to prevent this flaw from occurring.
8. Cross site request forgery
This attack forces a logged on victim’s browser to send forged HTTP requests to fake web pages. This may include the user’s session cookie and other authentication information. Browsers usually send credentials such as session cookies automatically. Attackers create malicious web pages that are capable of generating forged requests that cannot be distinguished from legitimate ones. They then trick users into submitting requests through XSS, image tags and other numerous techniques. If the user gets authenticated, the attack effectively succeeds.
You can prevent cross site forgery through including a unique token that is unpredictable in each HTTP request. Maximize the effectiveness of these tokens through:
- Including the unique token in a hidden field. This is the best option as it causes values to be sent in the HTTP request’s body hence preventing it from being included in the URL.
- Including the unique token in an URL parameter or in the URL itself. However, this method is slightly risky as the URL is at a risk of being exposed to the hacker, thereby compromising the secret unique token. Fortunately, the CSRF Guard from OWASP can automatically include unique tokens in Java, PHP or EE apps. ESAPI from OWASP has some methods that developers can use to prevent cross site request forgery vulnerability.
- Requiring users to re-authenticate or convincingly prove they are real users, for instance through the use of CAPTCHA.
9. Using components that have known vulnerabilities
Hackers identify weak components in an application through manual analysis or automated scanning. All applications have some flaws because developers don’t dedicate enough time in ensuring that all libraries/components are up to date.
The only clear way of preventing this flaw is through avoiding the use of any application that you didn’t write. Unfortunately, this is not very realistic. It is therefore important that you strictly monitor the security of all components of your applications through public databases, security and project mailing lists. Ensure all components are kept up to date.
You can also consider establishing security policies and rules governing the use of components, such as requiring all users to pass security tests, insisting on licenses and putting into place certain software development practices.
10. Invalidated redirects and forwards
This occur when a web application redirects and forwards users to other invalidated websites and pages. Hackers target unsafe forwards and redirects to bypass security checks. Such redirects may install malware or even trick users into disclosing sensitive credentials such as passwords; To find out whether your application has an invalidated forward or redirect, review the codes for all uses of forwards and redirects. In each case, find out whether the target URL is included in a parameter value. If the target URL is not validated on a whitelist, then your application is vulnerable.
To protect your applications against this flaw:
- Avoid using forwards and redirects
- If you use them, do not use users parameters in calculating destination
- If you cannot avoid destination parameters, ensure that all stipulated values are valid and authorized for the user
- Consider using ESAPI that can override the Send Redirect method to ensure all redirect destinations are safe and valid.
Attackers have taken advantage of the increase in number of active web applications to create automated tools that they can use to launch well-coordinated attacks against multiple vulnerable applications at once. Armed with these tools and a little knowledge on hacking, the targets of these hackers are not limited to large corporate web applications and websites.
The repercussions of having your applications compromised can be very devastating. Sensitive data may get stolen, user accounts might get compromised, your brand reputation will be damaged, your clients may lose confidence in you and you may end up losing sales revenue. There is therefore a need to eliminate all possible threats that exist on each web application. Avoiding the above ten discussed flaws is of uttermost importance as they are the favorite target for cyber criminals trying to gain users’ trust and confidence. Strictly follow the tips and leave nothing to chance as hackers are eagerly waiting for you to make just one single mistake.
