Bruter :: Web Form
The Web Form module tests accounts against Web Form authentication. The
application uses HTTP keep alive method. The application knows when connections have
to be disconnected.
Note: "Max Attempt/Connection" can be set to 0.
Note: This module cannot test against complicated web form authentication such as using
javascript to do hashing before sending a password.
Option(s)
This authentication is different from the other protocols. In order to use this option,
you need to know at least an URL that contains authentication form and what is the differrence
between login success and failure. You can automate filling Request options by put the URL and
click "Load Form" button (if you do not understand, just try to play with it).
Remark: If "Load Form" button does not work correctly, you need to fill in all required
information by yourself.
- Form URL: The URL that contains login form. If you do not want to use "Load Form" button, you can
ignore this field. But you must fill in other input fields manually.
- Method: A HTTP method. This program supports only 2 methods, GET and POST. You can get
this value manually from "method" attribute in HTML "form" tag. This input field usually is detected by
"Load Form" button.
- Target Page: A target URL that recieves and checks username/password. You can get this value manually from
"action" attribute in HTML "form" tag. This input field usually is detected by "Load Form" button.
- Cookie: Some targets need to set cookie before authentication process. You can set this value manually
from "Set-Cookie:" line in HTTP response header. This input field is usually detected by "Load Form" button.
- Cookie URL: If this value is not blank,
- Each thread will request to this URL to get cookie before testing. So each thread will have different cookie.
- Each thread will update cookie while testing if response header has "Set-Cookie:".
This value is usually the same as a "Form Page" value.
- Referer: A "Referer" in HTTP request. This value is usually the same as a "Form Page" value.
- User Agent: A "User Agent" in HTTP request. Currently, this program support only 4 types and you cannot
customize this value.
- Query String: A name/value in the form. This field value can be edited/inserted/deleted by using
below listview. There are special two values. Those are "%username%" and "%password%". "%username%" and
"%password%" will be replaced with username and password, respectively, while testing against the target.
You can get all name value from "name" attribute of input tag. All name fields usually are detected by
"Load Form" button, but those values might be wrong. You need to double-check them again.
- Follow redirection: This checkbox determines whether the application will request the redirected page
or not. The application will follow the redirection when got 301 or 302 and ONLY once.
Remark: In many cases, you do not need it because
- Normally the string that can be used to indicate login result is in HTTP redirection response.
- Sometimes the redirection is used for pass username and password to another page. You can manually input
the options to login directly to redirected page
- Use Negative Result: This checkbox determines whether below string is in login failure response
or login success response. This program searches the provided string in response text and decides what an outcome
will be based on conditions in the following table:
search found? | box is checked? | result |
yes | yes | failure |
yes | no | success |
no | yes | success |
no | no | failure |
- String: A string used to search in HTTP response.
Remark: Searching is case sensitive.
Remark: Searching also searches in HTTP response header.
Remark: Searching in body always fails if there is NULL in the body (normally because of UTF-16 and UTF-32 encoding).
Back