OWASP WebGoat Training Series

All Video tutorial by YGN Ethical Hacker Group

Download : OWASP WebGoat Training Series

DroidSQLi : First automated MySQL Injection tool for Android

DroidSQLi is the first automated MySQL Injection tool for Android. It allows you to test your MySQL-based web application against SQL injection attacks.

DroidSQLi supports the following injection techniques:
- Time based injection
- Blind injection
- Error based injection
- Normal injection

Click here to Download

Cross Site Request Forgery Vulnerability

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

Prevention measures that do NOT work

Using a secret cookie

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

Only accepting POST requests

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

Examples

How does the attack work?

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST http://bank.com/transfer.do HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

http://bank.com/transfer.do?acct=MARIA&amount=100000

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0">

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser will still submit the request to bank.com without any visual indication that the transfer has taken place.

Related Attacks

• Cross-site Scripting (XSS)


• Cross Site History Manipulation (XSHM)

Related Controls

• Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.


• TBD: Add a per-session nonce to URL and all forms


• TBD: Add a hash(session id, function name, server-side secret) to URL and all forms


• TBD: .NET - add session identifier to ViewState with MAC


• Checking the referrer in the client's HTTP request will prevent CSRF attacks. By ensuring the HTTP request have come from the original site means that the attacks from other sites will not function. It is very common to see referrer checks used on embedded network hardware due to memory limitations. XSS can be used to bypass both referrer and token based checks simultaneously. For instance the Sammy Worm used an XHR to obtain the CSRF token to forge requests.


• "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1


• Tokenizing

VIDEO :

Webapplication Attack : dos And ddos attacks[Video Demonstration]

What is a denial-of-service (DoS) attack?
In a denial-of-service (DoS) attack, an attacker attempts to prevent legitimate users from accessing information or services. By targeting your computer and its network connection, or the computers and network of the sites you are trying to use, an attacker may be able to prevent you from accessing email, websites, online accounts (banking, etc.), or other services that rely on the affected computer.

The most common and obvious type of DoS attack occurs when an attacker "floods" a network with information. When you type a URL for a particular website into your browser, you are sending a request to that site's computer server to view the page. The server can only process a certain number of requests at once, so if an attacker overloads the server with requests, it can't process your request. This is a "denial of service" because you can't access that site.

An attacker can use spam email messages to launch a similar attack on your email account. Whether you have an email account supplied by your employer or one available through a free service such as Yahoo or Hotmail, you are assigned a specific quota, which limits the amount of data you can have in your account at any given time. By sending many, or large, email messages to the account, an attacker can consume your quota, preventing you from receiving legitimate messages.

What is a distributed denial-of-service (DDoS) attack?
In a distributed denial-of-service (DDoS) attack, an attacker may use your computer to attack another computer. By taking advantage of security vulnerabilities or weaknesses, an attacker could take control of your computer. He or she could then force your computer to send huge amounts of data to a website or send spam to particular email addresses. The attack is "distributed" because the attacker is using multiple computers, including yours, to launch the denial-of-service attack.

dos and ddos attacks


Attacker exhaust available server resources by sending hundreds of resource-intensive requests,such as pulling out large image files or requesting dynamic pages that require expensive search operations on the backend database servers

Why Are Application Vulnerable?

• Reasonable Use Expectations


• Application Environment Bottlenecks


• Implementation Flaws


• poor Data Validation

Web Server Resource ConsumptionTargets

• CPU,Memory and Sockets


• Disk Bandwidth


• Database Bandwidth


• Worker Processes

Web Services UnavailabilityApplication-Level DOS attacks enulate the same request syntex and network-Level traffic characteristics as that of the legitimate clients,which makes it undetectable by existing DOS protection measures .

Login Attacks
The attacker may overload the login process by continually sending login requests that require the presentation tier to access the authentication mechanism,rendering it unavailable or unreasonably slow to respond.User Registration DOSThe attacker could create a program that submits the registration forms repeatedly ;adding a large number of squrious users to the application.

Account Lock-OUT Attacks

The attacker may enumerate username through another vulerability n the application and then attempt to authenticate to the site using valid username and incorrect passwords which will lock out the account after the specified number of failed attempts.At this point legitimate users will not be able to use the site .

User Enumeration

If application states which part of the username/password pair is incorrect,an attacker can automate the process of trying common usernames from a dictionary file to enumerate the users of the Application.

How do you know if an attack is happening?

Not all disruptions to service are the result of a denial-of-service attack. There may be technical problems with a particular network, or system administrators may be performing maintenance. However, the following symptoms could indicate a DoS or DDoS attack:

•     unusually slow network performance (opening files or accessing websites)


•     unavailability of a particular website


•     inability to access any website


•    dramatic increase in the amount of spam you receive in your account

How do you avoid being part of the problem?

Unfortunately, there are no effective ways to prevent being the victim of a DoS or DDoS attack, but there are steps you can take to reduce the likelihood that an attacker will use your computer to attack other computers:

•     Install and maintain anti-virus software (see Understanding Anti-Virus Software for more information).


•     Install a firewall, and configure it to restrict traffic coming into and leaving your computer (see Understanding Firewalls for more information).


•     Follow good security practices for distributing your email address (see Reducing Spam for more information). Applying email filters may help you manage unwanted traffic.