Login
SafeLine is a self-hosted WAF(Web Application Firewall) to protect your web apps from attacks and exploits.
A web application firewall helps protect web apps by filtering and monitoring HTTP traffic between a web application and the Internet. It typically protects web apps from attacks such as SQL injection, XSS, code injection, os command injection, CRLF injection, ldap injection, xpath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, http-flood, bot abused, among others.
By deploying a WAF in front of a web application, a shield is placed between the web application and the Internet. While a proxy server protects a client machine's identity by using an intermediary, a WAF is a type of reverse-proxy, protecting the server from exposure by having clients pass through the WAF before reaching the server.
A WAF protects your web apps by filtering, monitoring, and blocking any malicious HTTP/S traffic traveling to the web application, and prevents any unauthorized data from leaving the app. It does this by adhering to a set of policies that help determine what traffic is malicious and what traffic is safe. Just as a proxy server acts as an intermediary to protect the identity of a client, a WAF operates in similar fashion but acting as an reverse proxy intermediary that protects the web app server from a potentially malicious client.
its core capabilities include:
Get Live Demo
List of the main features as follows:
FreshRSS Block Web AttacksSQL injection, XSS, code injection, os command injection, CRLF injection, XXE, SSRF, path traversal and so on.Rate LimitingDoS attacks, bruteforce attempts, traffic surges, and other types of abuse by throttling traffic that exceeds defined limits.Anti-Bot Challengebot attacks, humen users will be allowed, crawlers and bots will be blocked.Authentication ChallengeDynamic Protection
bash git clone https://github.com/your_username/status-checker.git cd status-checker
bash pip install -r requirements.txt
python status_checker.py [-h] [-d DOMAIN] [-l LIST] [-o OUTPUT] [-v] [-update]
-d, --domain: Single domain/URL to check.-l, --list: File containing a list of domains/URLs to check.-o, --output: File to save the output.-v, --version: Display version information.-update: Update the tool.Example:
python status_checker.py -l urls.txt -o results.txt
This project is licensed under the MIT License - see the LICENSE file for details.
Find authentication (authn) and authorization (authz) security bugs in web application routes:
Web application HTTP route authn and authz bugs are some of the most common security issues found today. These industry standard resources highlight the severity of the issue:
Supported web frameworks (route-detect IDs in parentheses):
django, django-rest-framework), Flask (flask), Sanic (sanic)laravel), Symfony (symfony), CakePHP (cakephp)rails), Grape (grape)jax-rs), Spring (spring)gorilla), Gin (gin), Chi (chi)express), React (react), Angular (angular)*Rails support is limited. Please see this issue for more information.
Use pip to install route-detect:
$ python -m pip install --upgrade route-detect
You can check that route-detect is installed correctly with the following command:
$ echo 'print(1 == 1)' | semgrep --config $(routes which test-route-detect) -
Scanning 1 file.
Findings:
/tmp/stdin
routes.rules.test-route-detect
Found '1 == 1', your route-detect installation is working correctly
1┆ print(1 == 1)
Ran 1 rule on 1 file: 1 finding.
route-detect provides the routes CLI command and uses semgrep to search for routes.
Use the which subcommand to point semgrep at the correct web application rules:
$ semgrep --config $(routes which django) path/to/django/code
Use the viz subcommand to visualize route information in your browser:
$ semgrep --json --config $(routes which django) --output routes.json path/to/django/code
$ routes viz --browser routes.json
If you're not sure which framework to look for, you can use the special all ID to check everything:
$ semgrep --json --config $(routes which all) --output routes.json path/to/code
If you have custom authn or authz logic, you can copy route-detect's rules:
$ cp $(routes which django) my-django.yml
Then you can modify the rule as necessary and run it like above:
$ semgrep --json --config my-django.yml --output routes.json path/to/django/code
$ routes viz --browser routes.json
route-detect uses poetry for dependency and configuration management.
Before proceeding, install project dependencies with the following command:
$ poetry install --with dev
Lint all project files with the following command:
$ poetry run pre-commit run --all-files
Run Python tests with the following command:
$ poetry run pytest --cov
Run Semgrep rule tests with the following command:
$ poetry run semgrep --test --config routes/rules/ tests/test_rules/
A cutting-edge utility designed exclusively for web security aficionados, penetration testers, and system administrators. WebSecProbe is your advanced toolkit for conducting intricate web security assessments with precision and depth. This robust tool streamlines the intricate process of scrutinizing web servers and applications, allowing you to delve into the technical nuances of web security and fortify your digital assets effectively.
WebSecProbe is designed to perform a series of HTTP requests to a target URL with various payloads in order to test for potential security vulnerabilities or misconfigurations. Here's a brief overview of what the code does:
Does This Tool Bypass 403 ?
It doesn't directly attempt to bypass a 403 Forbidden status code. The code's purpose is more about testing the behavior of the server when different requests are made, including requests with various payloads, headers, and URL variations. While some of the payloads and headers in the code might be used in certain scenarios to test for potential security misconfigurations or weaknesses, it doesn't guarantee that it will bypass a 403 Forbidden status code.
In summary, this code is a tool for exploring and analyzing a web server's responses to different requests, but whether or not it can bypass a 403 Forbidden status code depends on the specific configuration and security measures implemented by the target server.
pip install WebSecProbe
WebSecProbe <URL> <Path>
Example:
WebSecProbe https://example.com admin-login
from WebSecProbe.main import WebSecProbe
if __name__ == "__main__":
url = 'https://example.com' # Replace with your target URL
path = 'admin-login' # Replace with your desired path
probe = WebSecProbe(url, path)
probe.run()
Skyhook is a REST-driven utility used to smuggle files into and out of networks defended by IDS implementations. It comes with a pre-packaged web client that uses a blend of React, vanilla JS, and web assembly to manage file transfers.
Note: See the user documentation for more thorough discussion of Skyhook and how it functions.
Skyhook's file transfer server seamlessly obfuscates file content with a user-configured series of obfuscation algorithms prior to writing the content to response bodies. Clients, which are configred with the same obfuscation algorithms, deobfuscate the file content prior to saving the file to disk. A file streaming technique is used to manage the HTTP transactions in a chunked manner, thus facilitating large file transfers.
flowchart
subgraph sg-cloudfront[Cloudfront CDN]
cf-listener(443/tls)
end
subgraph sg-vps[VPS]
subgraph sg-skyhook[Skyhook Servers]
admin-listener(Admin Server<br>45000/tls)
transfer-listener(Transfer Server<br>45001/tls)
end
config-file(Config File<br>/var/skyroot/config.yml)
admin-listener -..->|Reads &<br>Manages| config-file
webroot(Webroot<br>/var/skyhook/webroot)
transfer-listener -..->|Serves From &<br>Writes Cleartext<br>Files To| webroot
end
op-browser(Operator<br>Web Browser) -->|Administration<br>Traffic| admin-listener
op-browser <-->|Obfuscated<br>Data| transfer-listener
subgraph sg-corp[Corporate Environment]
subgraph sg-compromised[Beachhead Host]
comp-browser(Web Browser) -->|Reads &<b r>Writes| cleartext-file(Cleartext Files)
end
end
comp-browser <-->|Obfuscated<br>Data| cf-listener <-->|Obfuscated<br>Data| transfer-listener
For example, here is a working obfuscation configuration:
And here is the file transfer interface. Clicking "Download" results in the file being retrieved in chunks that are encrypted with the chain of obfuscation methods configured above.
JavaScript deobfuscates the file before prompting the user to save it to disk.
Below is a request stemming from a download being inspected with Burp. Key elements of the transaction are encrypted to evade detection.
surf allows you to filter a list of hosts, returning a list of viable SSRF candidates. It does this by sending a HTTP request from your machine to each host, collecting all the hosts that did not respond, and then filtering them into a list of externally facing and internally facing hosts.
You can then attempt these hosts wherever an SSRF vulnerability may be present. Due to most SSRF filters only focusing on internal or restricted IP ranges, you'll be pleasantly surprised when you get SSRF on an external IP that is not accessible via HTTP(s) from your machine.
Often you will find that large companies with cloud environments will have external IPs for internal web apps. Traditional SSRF filters will not capture this unless these hosts are specifically added to a blacklist (which they usually never are). This is why this technique can be so powerful.
This tool requires go 1.19 or above as we rely on httpx to do the HTTP probing.
It can be installed with the following command:
go install github.com/assetnote/surf/cmd/surf@latestConsider that you have subdomains for bigcorp.com inside a file named bigcorp.txt, and you want to find all the SSRF candidates for these subdomains. Here are some examples:
# find all ssrf candidates (including external IP addresses via HTTP probing)
surf -l bigcorp.txt
# find all ssrf candidates (including external IP addresses via HTTP probing) with timeout and concurrency settings
surf -l bigcorp.txt -t 10 -c 200
# find all ssrf candidates (including external IP addresses via HTTP probing), and just print all hosts
surf -l bigcorp.txt -d
# find all hosts that point to an internal/private IP address (no HTTP probing)
surf -l bigcorp.txt -xThe full list of settings can be found below:
❯ surf -h
███████╗██╗ ██╗██████╗ ███████╗
██╔════╝██║ ██║██╔══██╗██╔════╝
███████╗██║ ██║██████╔╝█████╗
╚════██║██║ ██║██╔══██╗██╔══╝
███████║╚██████╔ ██║ ██║██║
╚══════╝ ╚═════╝ ╚═╝ ╚═╝╚═╝
by shubs @ assetnote
Usage: surf [--hosts FILE] [--concurrency CONCURRENCY] [--timeout SECONDS] [--retries RETRIES] [--disablehttpx] [--disableanalysis]
Options:
--hosts FILE, -l FILE
List of assets (hosts or subdomains)
--concurrency CONCURRENCY, -c CONCURRENCY
Threads (passed down to httpx) - default 100 [default: 100]
--timeout SECONDS, -t SECONDS
Timeout in seconds (passed down to httpx) - default 3 [default: 3]
--retries RETRIES, -r RETRIES
Retries on failure (passed down to httpx) - default 2 [default: 2]
--disablehttpx, -x Disable httpx and only output list of hosts that resolve to an internal IP address - default false [default: false]
--disableanalysis, -d
Disable analysis and only output list of hosts - default false [default: false]
--help, -h display this help and exit
When running surf, it will print out the SSRF candidates to stdout, but it will also save two files inside the folder it is ran from:
external-{timestamp}.txt - Externally resolving, but unable to send HTTP requests to from your machineinternal-{timestamp}.txt - Internally resolving, and obviously unable to send HTTP requests from your machineThese two files will contain the list of hosts that are ideal SSRF candidates to try on your target. The external target list has higher chances of being viable than the internal list.
Under the hood, this tool leverages httpx to do the HTTP probing. It captures errors returned from httpx, and then performs some basic analysis to determine the most viable candidates for SSRF.
This tool was created as a result of a live hacking event for HackerOne (H1-4420 2023).
HTTP-Shell is Multiplatform Reverse Shell. This tool helps you to obtain a shell-like interface on a reverse connection over HTTP. Unlike other reverse shells, the main goal of the tool is to use it in conjunction with Microsoft Dev Tunnels, in order to get a connection as close as possible to a legitimate one.
This shell is not fully interactive, but displays any errors on screen (both Windows and Linux), is capable of uploading and downloading files, has command history, terminal cleanup (even with CTRL+L), automatic reconnection and movement between directories.
It is recommended to clone the complete repository or download the zip file. You can do this by running the following command:
git clone https://github.com/JoelGMSec/HTTP-Shell
https://darkbyte.net/obteniendo-shells-con-microsoft-dev-tunnels
This project is licensed under the GNU 3.0 license - see the LICENSE file for more details.
This tool has been created and designed from scratch by Joel Gámez Molina (@JoelGMSec).
This software does not offer any kind of guarantee. Its use is exclusive for educational environments and / or security audits with the corresponding consent of the client. I am not responsible for its misuse or for any possible damage caused by it.
For more information, you can find me on Twitter as @JoelGMSec and on my blog darkbyte.net.
DoSinator is a versatile Denial of Service (DoS) testing tool developed in Python. It empowers security professionals and researchers to simulate various types of DoS attacks, allowing them to assess the resilience of networks, systems, and applications against potential cyber threats.
Clone the repository:
git clone https://github.com/HalilDeniz/DoSinator.gitNavigate to the project directory:
cd DoSinatorInstall the required dependencies:
pip install -r requirements.txtusage: dos_tool.py [-h] -t TARGET -p PORT [-np NUM_PACKETS] [-ps PACKET_SIZE]
[-ar ATTACK_RATE] [-d DURATION] [-am {syn,udp,icmp,http,dns}]
[-sp SPOOF_IP] [--data DATA]
optional arguments:
-h, --help Show this help message and exit.
-t TARGET, --target TARGET
Target IP address.
-p PORT, --port PORT Target port number.
-np NUM_PACKETS, --num_packets NUM_PACKETS
Number of packets to send (default: 500).
-ps PACKET_SIZE, --packet_size PACKET_SIZE
Packet size in bytes (default: 64).
-ar ATTACK_RATE, --attack_rate ATTACK_RATE
Attack rate in packets per second (default: 10).
-d DURATION, --duration DURATION
Duration of the attack in seconds.
-am {syn,udp,icmp,htt p,dns}, --attack-mode {syn,udp,icmp,http,dns}
Attack mode (default: syn).
-sp SPOOF_IP, --spoof-ip SPOOF_IP
Spoof IP address.
--data DATA Custom data string to send.target_ip: IP address of the target system.target_port: Port number of the target service.num_packets: Number of packets to send (default: 500).packet_size: Size of each packet in bytes (default: 64).attack_rate: Attack rate in packets/second (default: 10).duration: Duration of the attack in seconds.attack_mode: Attack mode: syn, udp, icmp, http (default: syn).spoof_ip: Spoof IP address (default: None).data: Custom data string to send.The usage of the Dosinator tool for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state, and federal laws. The author assumes no liability and is not responsible for any misuse or damage caused by this program.
By using Dosinator, you agree to use this tool for educational and ethical purposes only. The author is not responsible for any actions or consequences resulting from misuse of this tool.
Please ensure that you have the necessary permissions to conduct any form of testing on a target network. Use this tool at your own risk.
Contributions are welcome! If you find any issues or have suggestions for improvements, feel free to open an issue or submit a pull request.
If you have any questions, comments, or suggestions about Dosinator, please feel free to contact me:
nas-1200
