mirror of
https://github.com/autistic-symposium/sec-pentesting-toolkit.git
synced 2025-04-27 11:09:09 -04:00
web exploit
This commit is contained in:
bt3gl
parent
662953c17a
commit
b54f50fbe4
@ -140,16 +140,84 @@ http://!$^&*()_+`-={}|[]:;@www.google.com
|
||||
|
||||
## HTTP
|
||||
|
||||
The first line of a request is modified to include protocol version information and it's followed by zero or more name:value pairs (headers):
|
||||
- User-Agent: browser version information
|
||||
- Host: URL hostanme
|
||||
- Accept: supported MIME documents( such as text/plain or audio/MPEG)
|
||||
- Accept-Language: supported language codes
|
||||
- Referer: originating page for the request
|
||||
* HTTP is a stateless protocol based on a series of client requests and web server responses.
|
||||
|
||||
The headers are terminated with a single empty line, which may be followerd by any payload the client wishes to pass to the server (the lenght should be specified with the Content-Length header). The payload is usually browser data, but there is no requirements.
|
||||
* HTTP requests and responses are comprised of Headers, followed by request or reponse body.
|
||||
|
||||
|
||||
* HTTP requests must use a specific request method.
|
||||
|
||||
* HTTP responses contain a Status Code.
|
||||
|
||||
* HTTP is a plain-text protocol.
|
||||
|
||||
* The first line of a request is modified to include protocol version information and it's followed by zero or more name:value pairs (headers):
|
||||
- User-Agent: browser version information
|
||||
- Host: URL hostanme
|
||||
- Accept: supported MIME documents( such as text/plain or audio/MPEG)
|
||||
- Accept-Language: supported language codes
|
||||
- Referer: originating page for the request
|
||||
|
||||
* The headers are terminated with a single empty line, which may be followerd by any payload the client wishes to pass to the server (the lenght should be specified with the Content-Length header).
|
||||
|
||||
* The payload is usually browser data, but there is no requirements.
|
||||
|
||||
|
||||
|
||||
### GET Method
|
||||
|
||||
* Passes all request data **within the URL QueryString**.
|
||||
|
||||
```
|
||||
GET /<URL QUERY STRING> HTTP/1.1
|
||||
User-Agent:Mozilla/4.0
|
||||
Host: <WESITE>
|
||||
<CRLF>
|
||||
<CRLF>
|
||||
```
|
||||
|
||||
### POST Method
|
||||
|
||||
* Passes all request data **within the HTTP request body**.
|
||||
|
||||
```
|
||||
POST /<LINK> HTTP/1.1
|
||||
User-Agent:Mozilla/4.0
|
||||
Host: <WEBSITE>
|
||||
Content-Lenght:16
|
||||
<CRLF><CRLF>
|
||||
name=John&type=2
|
||||
```
|
||||
|
||||
### HTTP Status Codes
|
||||
|
||||
* 1xx - informational
|
||||
* 2xx - sucess. Example: 200: 0K.
|
||||
* 3xx - redirection. Example: 302: Location.
|
||||
* 4xx - client error. Example: 403: Forbidden, 401: Unauthorized, 404: Not found.
|
||||
* 5xx - server error. Example: 500: Internal Server Error.
|
||||
|
||||
|
||||
### Session IDs
|
||||
|
||||
* HTTP protocol does not maintain state between requests. To maintain a state, must use a state tracking mechanism such as session identifier (session ID), which is passed within a request to associate requests with a session.
|
||||
|
||||
* Session ID's can be passed in these places:
|
||||
- URL
|
||||
- Hidden Form Field
|
||||
- Cookie HTTP Header
|
||||
|
||||
|
||||
#### Cookies
|
||||
|
||||
* To initiate a session, server sends a Set-Cookie header, which begins with a NAME=VALUE pair, followed by zero or more semi-colon-separated attribute-value pairs (Domain, Path, Expires, Secure).
|
||||
|
||||
```
|
||||
Set-Cookie: SID=472ndsw;expires=DATE;path=/;domain=SITE,HttpOnly
|
||||
```
|
||||
|
||||
* Client sends Cookie header to server to continue session.
|
||||
|
||||
|
||||
-----
|
||||
## Tools
|
||||
@ -159,7 +227,43 @@ The headers are terminated with a single empty line, which may be followerd by a
|
||||
|
||||
----
|
||||
|
||||
## CSRF
|
||||
## OWASP TOP 10
|
||||
|
||||
1. Injection
|
||||
2. XSS
|
||||
3. Broken Authentication and Session management
|
||||
4. Insecure Direct Object Reference
|
||||
5. CSRF
|
||||
6. Security Misconfiguration
|
||||
7. Insecure Cryptographic Storage
|
||||
8. Failure to Restrict URL access
|
||||
9. Insufficient Transport Layer Protection
|
||||
10. Unvalidated Redirects and Forwards.
|
||||
|
||||
|
||||
### Injection Flaws
|
||||
|
||||
* Happens when mixing Code and Input in the same context.
|
||||
* Hostile input is parsed as code by the interpreter.
|
||||
|
||||
#### SQL Injection
|
||||
|
||||
* For example an input text box for username and password. The server-side code can be:
|
||||
```
|
||||
String query = "SELECT user_id FROM user_data WHERE name = ' " + input.getValue("userID") + " ' and password = ' " + input.getValue("pwd") + " ' ";
|
||||
```
|
||||
|
||||
* The SQL query interpreted by the SQL Server:
|
||||
|
||||
```
|
||||
SELECT user_id FROM user_data WHERE name='john' and password='password'
|
||||
```
|
||||
|
||||
* However, if the attacker inputs **password' OR '1'='1**, no password is required!
|
||||
|
||||
* See sufolder SQLi for more information.
|
||||
|
||||
### CSRF
|
||||
|
||||
Identification and verification manual of CSRF can be done by checking in the website's forms (usually where most often find this vulnerability).
|
||||
|
||||
|
||||
@ -27,13 +27,38 @@ These types of flaws facilitate the occurrence of other attacks, such as XSS or
|
||||
|
||||
## Blind SQL Injection
|
||||
|
||||
It's estimated that over 20% of the websites have this flow.
|
||||
* INFERENCE: useful technique when data not returned and/or detailed error messages disabled. We can differentiate between two states based on some attribute of the page response.
|
||||
|
||||
In traditional SQLi it is possible to reveal the information by the attacker writing a payload. In the blind SQLi, the attacker needs to ask the server if something is TRUE or FALSE. For example, you can ask for a user. If the user exists, it will load the website, so it's true.
|
||||
* It's estimated that over 20% of the websites have this flow.
|
||||
|
||||
Every time you see an URL, the **question mark** followed by some type of letter or word means that a value is being sent from a page to another.
|
||||
* In traditional SQLi it is possible to reveal the information by the attacker writing a payload. In the blind SQLi, the attacker needs to ask the server if something is TRUE or FALSE. For example, you can ask for a user. If the user exists, it will load the website, so it's true.
|
||||
|
||||
In the example
|
||||
* Timing-based techniques: infer based on delaying database queries (sleep(), waitfor delay, etc).
|
||||
|
||||
```
|
||||
IF SYSTEM_USER="john" WAIFOR DELAY '0:0:15'
|
||||
```
|
||||
|
||||
* Response-based techniques (True or False): infer based on text in response. Examples:
|
||||
|
||||
```
|
||||
SELECT count (*) FROM reviews WHERE author='bob' (true)
|
||||
SELECT count (*) FROM reviews WHERE author='bob' and '1'='1' (true)
|
||||
SELECT count (*) FROM reviews WHERE author='bob' and '1'='2' (false)
|
||||
SELECT count (*) FROM reviews WHERE author='bob' and SYSTEM_USER='john' (false)
|
||||
SELECT count (*) FROM reviews WHERE author='bob' and SUBSTRING(SYSTEM_USER,1,1)='a' (false)
|
||||
SELECT count (*) FROM reviews WHERE author='bob' and SUBSTRING(SYSTEM_USER,1,1)='c' (true)
|
||||
```
|
||||
(and continue to iterate until finding the value of SYSTEM_USER).
|
||||
|
||||
* Utilize transport outside of HTTP response.
|
||||
|
||||
```
|
||||
|
||||
### Common ways of Exploitation
|
||||
* Every time you see an URL, the **question mark** followed by some type of letter or word means that a value is being sent from a page to another.
|
||||
|
||||
* In the example
|
||||
```
|
||||
http://www.website.com/info.php?id=10
|
||||
```
|
||||
@ -45,7 +70,8 @@ and an associated SQL query:
|
||||
```
|
||||
QueryHere = "select * from information where code='$id'"
|
||||
```
|
||||
### Common ways of Exploitation
|
||||
|
||||
|
||||
|
||||
#### Checking for vulnerability
|
||||
We can start to verifying whether the target is vulnerable by attaching a simple quote symbol ```'``` in the end of the URL:
|
||||
@ -120,6 +146,29 @@ This will return information about the columns in the given table.
|
||||
|
||||
If the password are clear text (not hashed in md5, etc), we have access to the website.
|
||||
|
||||
## Basic SQL Injection Exploit Steps
|
||||
|
||||
1. Fingerprint database server.
|
||||
2. Get an initial working exploit. Examples of payloads:
|
||||
- '
|
||||
- '--
|
||||
- ')--
|
||||
- '))--
|
||||
- or '1'='1'
|
||||
- or '1'='1
|
||||
- 1--
|
||||
3. Extract data through UNION statements:
|
||||
- NULL: use as a column place holder helps with data type conversion errors
|
||||
- GROUP BY - help determine number of columns
|
||||
4. Enumerate database schema.
|
||||
5. Dump application data.
|
||||
6. Escalate privilege and pwn the OS.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Some Protection Tips
|
||||
|
||||
* Never connect to a database as a super user or as a root.
|
||||
@ -143,7 +192,7 @@ $SQL = "SELECT * FROM users WHERE username='$name'";
|
||||
- The chars to be checked:```", ', whitespace, ;, =, <, >, !, --, #, //```.
|
||||
- The reserved words: SELECT, INSERT, UPDATE, DELETE, JOIN, WHERE, LEFT, INNER, NOT, IN, LIKE, TRUNCATE, DROP, CREATE, ALTER, DELIMITER.
|
||||
|
||||
* Do not display explicit error messages that show the request or a part of the SQL request.
|
||||
* Do not display explicit error messages that show the request or a part of the SQL request. They can helpfingerprint the RDBMS(MSSQL, MySQL).
|
||||
|
||||
* Erase user accounts that are not used (and default accounts).
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user