mirror of
https://github.com/autistic-symposium/sec-pentesting-toolkit.git
synced 2025-05-02 06:46:07 -04:00
web exploit
This commit is contained in:
parent
662953c17a
commit
b54f50fbe4
2 changed files with 167 additions and 14 deletions
|
@ -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).
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue