sentinel-scanner 2.4.1 → 2.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.cspell.json +19 -51
- package/.github/ISSUE_TEMPLATE/config.yml +1 -1
- package/.github/PULL_REQUEST_TEMPLATE.md +2 -2
- package/.github/workflows/stale.yaml +20 -0
- package/.github/workflows/webapp-scanner.yml +31 -19
- package/.github/workflows/welcome.yaml +9 -55
- package/.husky/pre-commit +35 -0
- package/.vscode/extensions.json +7 -0
- package/.vscode/launch.json +20 -0
- package/.vscode/settings.json +32 -0
- package/.vscode/tasks.json +24 -0
- package/CHANGELOG.md +7 -3
- package/CODE_OF_CONDUCT.md +4 -1
- package/CONTRIBUTING.md +2 -2
- package/README.md +5 -0
- package/api-extractor.json +30 -30
- package/biome.json +6 -32
- package/build/index.d.ts +0 -147
- package/build/index.js +111 -2633
- package/package.json +69 -102
- package/scripts/build.ts +68 -78
- package/scripts/test.ts +55 -0
- package/src/__tests__/spider.test.ts +44 -0
- package/src/commands/spider.ts +61 -126
- package/src/index.ts +23 -26
- package/src/spider/index.ts +345 -0
- package/src/spider/types/index.ts +21 -0
- package/src/spider/types/schema.ts +54 -0
- package/src/utils/index.ts +199 -3
- package/tsconfig.json +19 -18
- package/.github/assets/header.png +0 -0
- package/.github/dependabot.yml +0 -11
- package/.github/workflows/pr.yaml +0 -64
- package/.nsprc +0 -3
- package/build/bin.js +0 -2679
- package/build/xhr-sync-worker.js +0 -59
- package/docs/CNAME +0 -1
- package/docs/disclaimer.md +0 -68
- package/docs/headers/details.md +0 -114
- package/docs/headers/index.md +0 -73
- package/docs/index.md +0 -82
- package/docs/ports/index.md +0 -86
- package/docs/scoring.md +0 -91
- package/docs/spider/index.md +0 -61
- package/docs/sql-injection/details.md +0 -109
- package/docs/sql-injection/index.md +0 -73
- package/docs/xss/details.md +0 -92
- package/docs/xss/index.md +0 -73
- package/scripts/extras/document-shim.js +0 -4
- package/src/bin.ts +0 -29
- package/src/commands/header.ts +0 -150
- package/src/commands/ports.ts +0 -175
- package/src/commands/sqli.ts +0 -150
- package/src/commands/xss.ts +0 -149
- package/src/modules/headers/headers.ts +0 -161
- package/src/modules/headers/index.ts +0 -179
- package/src/modules/ports/index.ts +0 -311
- package/src/modules/spider/index.ts +0 -178
- package/src/modules/sqli/index.ts +0 -486
- package/src/modules/sqli/payloads.json +0 -156
- package/src/modules/xss/index.ts +0 -401
- package/src/modules/xss/payloads.json +0 -2692
- package/src/utils/types.ts +0 -7
@@ -1,109 +0,0 @@
|
|
1
|
-
---
|
2
|
-
layout: default
|
3
|
-
title: Sentinel by Rebackk | SQL Injection Details
|
4
|
-
---
|
5
|
-
### **Understanding SQL Injection (SQLi): Protecting Your Web Applications**
|
6
|
-
|
7
|
-
#### **Introduction**
|
8
|
-
SQL Injection (SQLi) is one of the most dangerous and prevalent web vulnerabilities, regularly appearing on the OWASP Top Ten list. Attackers exploit SQLi to manipulate backend databases through malicious SQL queries. By injecting malicious code into a website's input fields or URL parameters, attackers can view, modify, or delete data, potentially leading to significant security breaches. In this guide, we’ll explore what SQL Injection is, the different types of SQLi attacks, real-world examples, and how you can protect your applications using Rebackk's Sentinel tool.
|
9
|
-
|
10
|
-
---
|
11
|
-
|
12
|
-
### **What is SQL Injection (SQLi)?**
|
13
|
-
SQL Injection is a vulnerability that allows attackers to interfere with the queries your application sends to its database. By injecting malicious SQL code into input fields (like login forms, search bars, or URL parameters), attackers can manipulate or extract sensitive data, bypass authentication, or even execute administrative database commands.
|
14
|
-
|
15
|
-
#### **Types of SQL Injection Attacks**
|
16
|
-
1. **In-band SQLi (Classic SQLi)**:
|
17
|
-
This is the most common form of SQLi. The attacker uses the same communication channel to both launch the attack and gather results, such as through error messages or retrieving data from the database.
|
18
|
-
|
19
|
-
2. **Blind SQLi**:
|
20
|
-
In this type of attack, the attacker does not get the results directly. Instead, they infer the presence of vulnerabilities based on the application's behavior (e.g., timing or changes in responses). Blind SQLi is more difficult to detect but still dangerous.
|
21
|
-
|
22
|
-
- **Boolean-based Blind SQLi**: The attacker sends a query that forces the application to return different results depending on the condition (true or false).
|
23
|
-
- **Time-based Blind SQLi**: The attacker induces a delay in the database response, which helps infer whether the query is correct.
|
24
|
-
|
25
|
-
3. **Out-of-Band SQLi**:
|
26
|
-
This type of SQLi is rare but sophisticated. The attacker relies on the server’s ability to make DNS or HTTP requests to a remote server. Results are retrieved through these external channels, such as by creating DNS requests or HTTP responses.
|
27
|
-
|
28
|
-
---
|
29
|
-
|
30
|
-
### **How SQL Injection Works: A Real-World Example**
|
31
|
-
|
32
|
-
Consider a user visiting a login page with a vulnerable form. If the application doesn’t properly sanitize user input, an attacker could enter the following SQL code in the username or password field:
|
33
|
-
|
34
|
-
```sql
|
35
|
-
' OR 1=1 --
|
36
|
-
```
|
37
|
-
|
38
|
-
This could turn the SQL query into:
|
39
|
-
|
40
|
-
```sql
|
41
|
-
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = 'userpassword';
|
42
|
-
```
|
43
|
-
|
44
|
-
Since `1=1` is always true, the query would return all records in the database, potentially allowing the attacker to bypass authentication and gain unauthorized access to the system.
|
45
|
-
|
46
|
-
---
|
47
|
-
|
48
|
-
### **How to Detect SQL Injection Vulnerabilities**
|
49
|
-
Using **Sentinel**, Rebackk’s AI-powered vulnerability scanner, you can easily detect SQL Injection vulnerabilities in your web applications. Here’s how to use it:
|
50
|
-
|
51
|
-
1. **Run a Scan**:
|
52
|
-
```bash
|
53
|
-
npx sentinel-scanner sqli -s <path_to_spider_results>
|
54
|
-
```
|
55
|
-
2. **Analyze the Results**:
|
56
|
-
- Sentinel generates a detailed report, highlighting any SQLi vulnerabilities detected in your web application.
|
57
|
-
- It offers actionable recommendations to fix the vulnerabilities.
|
58
|
-
|
59
|
-
---
|
60
|
-
|
61
|
-
### **Best Practices for Preventing SQL Injection Attacks**
|
62
|
-
|
63
|
-
1. **Use Prepared Statements (Parameterized Queries)**:
|
64
|
-
- Prepared statements ensure that user inputs are treated as data and not executable code. This is the most effective way to prevent SQLi.
|
65
|
-
|
66
|
-
Example (in PHP with PDO):
|
67
|
-
```php
|
68
|
-
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username');
|
69
|
-
$stmt->execute(['username' => $userInput]);
|
70
|
-
```
|
71
|
-
|
72
|
-
2. **Sanitize and Escape User Inputs**:
|
73
|
-
- Use input validation and sanitization to ensure that data entered by users is safe.
|
74
|
-
- Use functions like `mysqli_real_escape_string` (in PHP) to escape dangerous characters.
|
75
|
-
|
76
|
-
3. **Use ORM (Object-Relational Mapping) Frameworks**:
|
77
|
-
- ORM libraries automatically handle query generation, reducing the risk of SQLi by using parameterized queries behind the scenes.
|
78
|
-
|
79
|
-
4. **Limit Database Permissions**:
|
80
|
-
- Ensure that the database account used by the web application has the least amount of privilege necessary to function. For example, avoid using an admin account for web application queries.
|
81
|
-
|
82
|
-
5. **Error Handling**:
|
83
|
-
- Avoid exposing detailed database error messages to users. Use generic error messages to prevent attackers from gaining insight into your database structure.
|
84
|
-
|
85
|
-
6. **Implement Web Application Firewalls (WAF)**:
|
86
|
-
- A WAF can help detect and block malicious SQLi attempts before they reach your application.
|
87
|
-
|
88
|
-
---
|
89
|
-
|
90
|
-
### **Using Rebackk’s Sentinel for Continuous Security**
|
91
|
-
With Sentinel’s automated scanning, you can set up continuous monitoring to detect SQL Injection vulnerabilities before attackers exploit them.
|
92
|
-
|
93
|
-
**Key Features**:
|
94
|
-
- **AI-Powered Analysis**: Quickly scans your web apps for SQLi vulnerabilities.
|
95
|
-
- **Detailed Reports**: Provides step-by-step guides on how to fix detected issues.
|
96
|
-
- **OWASP Top Ten Coverage**: Ensures protection against common vulnerabilities like SQLi, XSS, and more.
|
97
|
-
|
98
|
-
---
|
99
|
-
|
100
|
-
### **Conclusion**
|
101
|
-
SQL Injection remains one of the most critical vulnerabilities in web applications, but by applying best practices and using tools like Rebackk’s Sentinel, you can protect your application from these dangerous attacks. Regularly scan your applications, sanitize inputs, and implement security best practices to stay ahead of attackers.
|
102
|
-
|
103
|
-
Start securing your applications today with **Sentinel**. Visit [Rebackk](https://rebackk.xyz) to learn more and try it for free.
|
104
|
-
|
105
|
-
---
|
106
|
-
|
107
|
-
#### **Additional Resources**
|
108
|
-
- [OWASP SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)
|
109
|
-
- [Sentinel Web App Scanner Documentation](https://rebackkhq.github.io/webapp-scanner/)
|
@@ -1,73 +0,0 @@
|
|
1
|
-
---
|
2
|
-
layout: default
|
3
|
-
title: Sentinel by Rebackk | SQLi Scanner
|
4
|
-
---
|
5
|
-
## Sentinel by Rebackk | SQLi Scanner Intro
|
6
|
-
|
7
|
-
# 🛡️ SQLi Scanner
|
8
|
-
|
9
|
-
A powerful SQL Injection (SQLi) vulnerability scanner that uses the output from a Spider crawler to identify SQL Injection vulnerabilities on each page of a website. It supports concurrency, retries, and customizable timeouts, ensuring efficient and thorough scanning.
|
10
|
-
|
11
|
-
## Features
|
12
|
-
|
13
|
-
- **Leverages Spider Results**: Uses URLs collected by the Spider tool to perform targeted SQL Injection scanning.
|
14
|
-
- **Customizable Concurrency**: Supports multiple requests in parallel to speed up the scanning process.
|
15
|
-
- **Retries on Failure**: Automatically retries failed requests to ensure reliable results.
|
16
|
-
- **Timeout Handling**: Configurable timeout for each request to manage slow or unresponsive pages.
|
17
|
-
- **Output in JSON Format**: Saves the scan results in a detailed and easily accessible JSON file.
|
18
|
-
- **Command Line Interface (CLI)**: Provides a simple yet powerful CLI for quick and flexible scanning.
|
19
|
-
|
20
|
-
## Installation and Usage
|
21
|
-
|
22
|
-
### Using NPM Exec
|
23
|
-
|
24
|
-
- Install the `sentinel-scanner` globally:
|
25
|
-
```bash
|
26
|
-
npm install -g sentinel-scanner
|
27
|
-
```
|
28
|
-
|
29
|
-
- Run the **SQLi Scanner** using the Spider results:
|
30
|
-
```bash
|
31
|
-
npx sentinel-scanner sqli -s <path_to_spider_results>
|
32
|
-
```
|
33
|
-
|
34
|
-
## Using PreBuilt Releases
|
35
|
-
|
36
|
-
- Download the [Latest Release](https://github.com/RebackkHQ/webapp-scanner/releases/latest).
|
37
|
-
- Extract the files.
|
38
|
-
- Run the SQLi Scanner from the command line:
|
39
|
-
```bash
|
40
|
-
npx . sqli -s <path_to_spider_results>
|
41
|
-
```
|
42
|
-
|
43
|
-
## Parameters
|
44
|
-
|
45
|
-
### Options
|
46
|
-
|
47
|
-
| Option | Alias | Type | Default | Description |
|
48
|
-
|--------------------|-------|----------|----------------------------------------------|-------------------------------------------------------------------|
|
49
|
-
| `--spiderResults` | `-s` | `string` | - | Path to the spider results file (**required**). |
|
50
|
-
| `--output` | `-o` | `string` | `sentinel_output/sqliResult_<timestamp>.json` | Path to save the output JSON file. |
|
51
|
-
| `--concurrency` | `-c` | `number` | 10 | Number of concurrent requests (range: 1-20). |
|
52
|
-
| `--timeout` | `-t` | `number` | 5000 (ms) | Timeout for each request in milliseconds (range: 0-25,000). |
|
53
|
-
| `--retries` | `-r` | `number` | 3 | Number of retries for each request (range: 0-10). |
|
54
|
-
|
55
|
-
## Example Commands
|
56
|
-
|
57
|
-
### Basic Scan
|
58
|
-
To scan for SQL Injection vulnerabilities using Spider results:
|
59
|
-
```bash
|
60
|
-
npx sentinel-scanner sqli -s spiderResults.json
|
61
|
-
```
|
62
|
-
|
63
|
-
### Advanced Scan with Custom Output and Concurrency
|
64
|
-
To scan with custom concurrency, timeout, and output path:
|
65
|
-
```bash
|
66
|
-
npx sentinel-scanner sqli -s spiderResults.json -c 15 -t 8000 -o ./output/sqliScanResults.json
|
67
|
-
```
|
68
|
-
|
69
|
-
### Default Output Path
|
70
|
-
If the `--output` option is not specified, the results will be saved to:
|
71
|
-
```
|
72
|
-
sentinel_output/sqliResult_<timestamp>.json
|
73
|
-
```
|
package/docs/xss/details.md
DELETED
@@ -1,92 +0,0 @@
|
|
1
|
-
---
|
2
|
-
layout: default
|
3
|
-
title: Sentinel by Rebackk | XSS Details
|
4
|
-
---
|
5
|
-
### **Understanding Cross-Site Scripting (XSS): Protecting Your Web Applications**
|
6
|
-
|
7
|
-
#### **Introduction**
|
8
|
-
In the age of digital transformation, web security has become a critical aspect of any business. Cross-Site Scripting (XSS) is one of the most common and dangerous vulnerabilities, frequently appearing on the OWASP Top Ten list. Attackers exploit XSS to inject malicious scripts into web applications, potentially compromising sensitive data or taking control of user sessions. In this guide, we'll explore what XSS is, its different types, real-world examples, and how you can protect your applications using Rebackk's Sentinel tool.
|
9
|
-
|
10
|
-
---
|
11
|
-
|
12
|
-
### **What is Cross-Site Scripting (XSS)?**
|
13
|
-
Cross-Site Scripting (XSS) is a security vulnerability that allows attackers to inject malicious scripts into otherwise trusted websites. These scripts run in the context of a user’s browser, leading to data theft, session hijacking, or defacement of web pages.
|
14
|
-
|
15
|
-
#### **Types of XSS Attacks**
|
16
|
-
1. **Stored XSS**: The malicious script is permanently stored on the target server (e.g., in a database). When users access the affected page, the script executes in their browser.
|
17
|
-
2. **Reflected XSS**: The attacker's payload is reflected off a web server, typically in error messages or search results. The script is executed immediately when a user interacts with a specially crafted URL.
|
18
|
-
3. **DOM-Based XSS**: The vulnerability exists in the client-side code rather than the server-side. It occurs when JavaScript modifies the DOM with untrusted data, leading to script execution.
|
19
|
-
|
20
|
-
---
|
21
|
-
|
22
|
-
### **How XSS Works: A Real-World Example**
|
23
|
-
|
24
|
-
Imagine a user visiting a website with a vulnerable comment section. If the website does not sanitize user inputs, an attacker could insert the following script:
|
25
|
-
|
26
|
-
```html
|
27
|
-
<script>alert('You have been hacked!');</script>
|
28
|
-
```
|
29
|
-
|
30
|
-
Whenever someone views the infected page, the script will execute, showing an alert box. While this example is harmless, real attacks can steal cookies, redirect users, or perform actions on behalf of the victim.
|
31
|
-
|
32
|
-
---
|
33
|
-
|
34
|
-
### **How to Detect XSS Vulnerabilities**
|
35
|
-
Using **Sentinel**, Rebackk’s AI-powered vulnerability scanner, you can quickly identify XSS vulnerabilities in your web applications. Here's how it works:
|
36
|
-
|
37
|
-
1. **Run a Scan**:
|
38
|
-
```bash
|
39
|
-
npx sentinel-scanner --target https://yourwebsite.com
|
40
|
-
```
|
41
|
-
2. **Analyze the Results**:
|
42
|
-
- Sentinel provides detailed reports highlighting any vulnerabilities found, including potential XSS issues.
|
43
|
-
- It offers recommendations on how to patch these vulnerabilities.
|
44
|
-
|
45
|
-
---
|
46
|
-
|
47
|
-
### **Best Practices for Preventing XSS Attacks**
|
48
|
-
|
49
|
-
1. **Input Validation and Sanitization**:
|
50
|
-
- Use libraries like DOMPurify to sanitize user-generated content.
|
51
|
-
- Avoid using `innerHTML` to insert data into the DOM. Instead, use `textContent` or safer methods.
|
52
|
-
|
53
|
-
2. **Escape User Inputs**:
|
54
|
-
- Escape data based on the context (HTML, JavaScript, CSS, etc.).
|
55
|
-
- Use security headers like `Content-Security-Policy (CSP)` to prevent script execution.
|
56
|
-
|
57
|
-
```http
|
58
|
-
Content-Security-Policy: script-src 'self';
|
59
|
-
```
|
60
|
-
|
61
|
-
3. **Implement HTTP-Only and Secure Cookies**:
|
62
|
-
- Use `HttpOnly` and `Secure` flags for cookies to prevent attackers from accessing session data.
|
63
|
-
- Example:
|
64
|
-
```http
|
65
|
-
Set-Cookie: sessionId=abc123; HttpOnly; Secure
|
66
|
-
```
|
67
|
-
|
68
|
-
4. **Enable Web Application Firewalls (WAF)**:
|
69
|
-
- A WAF can help detect and block malicious traffic before it reaches your application.
|
70
|
-
|
71
|
-
---
|
72
|
-
|
73
|
-
### **Using Rebackk’s Sentinel for Continuous Security**
|
74
|
-
With Sentinel’s automated scanning, you can set up continuous monitoring to detect XSS vulnerabilities before attackers do.
|
75
|
-
|
76
|
-
**Key Features**:
|
77
|
-
- **AI-Powered Analysis**: Quickly scans your web apps for known and emerging threats.
|
78
|
-
- **Detailed Reports**: Provides step-by-step guides on how to fix detected issues.
|
79
|
-
- **OWASP Top Ten Coverage**: Ensures protection against common vulnerabilities like XSS, SQL Injection, and more.
|
80
|
-
|
81
|
-
---
|
82
|
-
|
83
|
-
### **Conclusion**
|
84
|
-
Cross-Site Scripting remains a critical threat to web applications, but by implementing best practices and leveraging tools like Rebackk’s Sentinel, you can protect your business from potential attacks. Regularly scan your applications, enforce strong security policies, and stay ahead of the evolving threat landscape.
|
85
|
-
|
86
|
-
Start your journey towards a secure web experience by trying **Sentinel for free** today. Visit [Rebackk](https://rebackk.xyz) to learn more.
|
87
|
-
|
88
|
-
---
|
89
|
-
|
90
|
-
#### **Additional Resources**
|
91
|
-
- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Prevention_Cheat_Sheet.html)
|
92
|
-
- [Sentinel Web App Scanner Documentation](https://rebackkhq.github.io/webapp-scanner/)
|
package/docs/xss/index.md
DELETED
@@ -1,73 +0,0 @@
|
|
1
|
-
---
|
2
|
-
layout: default
|
3
|
-
title: Sentinel by Rebackk | XSS Scanner
|
4
|
-
---
|
5
|
-
## Sentinel by Rebackk | XSS Scanner Intro
|
6
|
-
|
7
|
-
# 🛡️ XSS Scanner
|
8
|
-
|
9
|
-
A robust XSS vulnerability scanner that leverages the output from the Spider crawler to identify Cross-Site Scripting (XSS) vulnerabilities on each page of a website. It supports concurrency, retries, and configurable timeouts, ensuring efficient and thorough scanning.
|
10
|
-
|
11
|
-
## Features
|
12
|
-
|
13
|
-
- **Leverages Spider Results**: Uses URLs collected by the Spider tool to perform targeted XSS scanning.
|
14
|
-
- **Customizable Concurrency**: Supports multiple requests in parallel to accelerate scanning.
|
15
|
-
- **Retries on Failure**: Automatically retries failed requests to ensure reliable results.
|
16
|
-
- **Timeout Handling**: Configurable timeout for each request to manage slow responses.
|
17
|
-
- **Output in JSON Format**: Saves the scan results in a detailed JSON file.
|
18
|
-
- **Command Line Interface (CLI)**: Provides a simple yet powerful CLI for quick scans.
|
19
|
-
|
20
|
-
## Installation and Usage
|
21
|
-
|
22
|
-
### Using NPM Exec
|
23
|
-
|
24
|
-
- Install the `sentinel-scanner` globally:
|
25
|
-
```bash
|
26
|
-
npm install -g sentinel-scanner
|
27
|
-
```
|
28
|
-
|
29
|
-
- Run the **XSS Scanner** using the Spider results:
|
30
|
-
```bash
|
31
|
-
npx sentinel-scanner xss -s <path_to_spider_results>
|
32
|
-
```
|
33
|
-
|
34
|
-
## Using PreBuilt Releases
|
35
|
-
|
36
|
-
- Download the [Latest Release](https://github.com/RebackkHQ/webapp-scanner/releases/latest).
|
37
|
-
- Extract the files.
|
38
|
-
- Run the XSS Scanner from the command line:
|
39
|
-
```bash
|
40
|
-
npx . xss -s <path_to_spider_results>
|
41
|
-
```
|
42
|
-
|
43
|
-
## Parameters
|
44
|
-
|
45
|
-
### Options
|
46
|
-
|
47
|
-
| Option | Alias | Type | Default | Description |
|
48
|
-
|--------------------|-------|----------|----------------------------------------------|------------------------------------------------------------------|
|
49
|
-
| `--spiderResults` | `-s` | `string` | - | Path to the spider results file (**required**). |
|
50
|
-
| `--output` | `-o` | `string` | `sentinel_output/xssResult_<timestamp>.json` | Path to save the output JSON file. |
|
51
|
-
| `--concurrency` | `-c` | `number` | 10 | Number of concurrent requests (range: 1-20). |
|
52
|
-
| `--timeout` | `-t` | `number` | 5000 (ms) | Timeout for each request in milliseconds (range: 0-25,000). |
|
53
|
-
| `--retries` | `-r` | `number` | 3 | Number of retries for each request (range: 0-10). |
|
54
|
-
|
55
|
-
## Example Commands
|
56
|
-
|
57
|
-
### Basic Scan
|
58
|
-
To scan for XSS vulnerabilities using Spider results:
|
59
|
-
```bash
|
60
|
-
npx sentinel-scanner xss -s spiderResults.json
|
61
|
-
```
|
62
|
-
|
63
|
-
### Advanced Scan with Custom Output and Concurrency
|
64
|
-
To scan with custom concurrency, timeout, and output path:
|
65
|
-
```bash
|
66
|
-
npx sentinel-scanner xss -s spiderResults.json -c 15 -t 8000 -o ./output/xssScanResults.json
|
67
|
-
```
|
68
|
-
|
69
|
-
### Default Output Path
|
70
|
-
If the `--output` option is not specified, the results will be saved to:
|
71
|
-
```
|
72
|
-
sentinel_output/xssResult_<timestamp>.json
|
73
|
-
```
|
package/src/bin.ts
DELETED
@@ -1,29 +0,0 @@
|
|
1
|
-
#!/usr/bin/env node --no-warnings
|
2
|
-
|
3
|
-
import yargs from "yargs";
|
4
|
-
import { hideBin } from "yargs/helpers";
|
5
|
-
import { headerCommand } from "./commands/header.js";
|
6
|
-
import { portsCommand } from "./commands/ports.js";
|
7
|
-
import { spiderCommand } from "./commands/spider.js";
|
8
|
-
import { sqliCommand } from "./commands/sqli.js";
|
9
|
-
import { xssCommand } from "./commands/xss.js";
|
10
|
-
|
11
|
-
const commandHandler = yargs(hideBin(process.argv));
|
12
|
-
|
13
|
-
commandHandler.demandCommand();
|
14
|
-
commandHandler.scriptName("sentinel-scanner");
|
15
|
-
commandHandler.usage("Usage: $0 <command> [options]");
|
16
|
-
commandHandler.help().alias("help", "h");
|
17
|
-
commandHandler.version().alias("version", "v");
|
18
|
-
commandHandler.strict();
|
19
|
-
commandHandler.showHelpOnFail(true);
|
20
|
-
|
21
|
-
// Handle Commands
|
22
|
-
commandHandler.command(spiderCommand);
|
23
|
-
commandHandler.command(xssCommand);
|
24
|
-
commandHandler.command(headerCommand);
|
25
|
-
commandHandler.command(sqliCommand);
|
26
|
-
commandHandler.command(portsCommand);
|
27
|
-
|
28
|
-
commandHandler.version().alias("version", "v");
|
29
|
-
commandHandler.parse();
|
package/src/commands/header.ts
DELETED
@@ -1,150 +0,0 @@
|
|
1
|
-
import fs from "node:fs/promises";
|
2
|
-
import path from "node:path";
|
3
|
-
import type { ArgumentsCamelCase, CommandModule } from "yargs";
|
4
|
-
import { HeaderScanner, XSSScanner } from "../index.js";
|
5
|
-
import { createLogger } from "../utils/index.js";
|
6
|
-
|
7
|
-
export type HeaderScannerCLIOpts = {
|
8
|
-
spiderResults: string;
|
9
|
-
retries?: number;
|
10
|
-
timeout?: number;
|
11
|
-
concurrency?: number;
|
12
|
-
output?: string;
|
13
|
-
};
|
14
|
-
|
15
|
-
const cliLogger = createLogger("CLI");
|
16
|
-
|
17
|
-
export const headerCommand: CommandModule = {
|
18
|
-
command: "header",
|
19
|
-
describe:
|
20
|
-
"Check a website for Header vulnerabilities. Checks for security and information leak headers",
|
21
|
-
builder: (yargs) => {
|
22
|
-
return yargs
|
23
|
-
.option("spiderResults", {
|
24
|
-
alias: "s",
|
25
|
-
type: "string",
|
26
|
-
description:
|
27
|
-
"The spider results file to use for scanning. It will use the URLs from the spider results to scan for header vulnerabilities",
|
28
|
-
demandOption: true,
|
29
|
-
coerce: (url) => {
|
30
|
-
if (!path.isAbsolute(url)) {
|
31
|
-
return path.resolve(url);
|
32
|
-
}
|
33
|
-
return url;
|
34
|
-
},
|
35
|
-
})
|
36
|
-
.option("output", {
|
37
|
-
alias: "o",
|
38
|
-
type: "string",
|
39
|
-
description:
|
40
|
-
"The output file to write the results to. Must be a JSON file",
|
41
|
-
default: () => getDefaultFilePath(),
|
42
|
-
coerce: (output) => {
|
43
|
-
const resolvedPath = path.resolve(output);
|
44
|
-
const { ext } = path.parse(resolvedPath);
|
45
|
-
|
46
|
-
if (ext !== ".json") {
|
47
|
-
throw new Error("Output file must be a JSON file");
|
48
|
-
}
|
49
|
-
return resolvedPath;
|
50
|
-
},
|
51
|
-
})
|
52
|
-
.option("concurrency", {
|
53
|
-
alias: "c",
|
54
|
-
type: "number",
|
55
|
-
description: "The number of concurrent requests to make",
|
56
|
-
default: 10,
|
57
|
-
coerce: (concurrency) => {
|
58
|
-
if (concurrency < 1 || concurrency > 20) {
|
59
|
-
throw new Error("Concurrency must be between 1 and 20");
|
60
|
-
}
|
61
|
-
return concurrency;
|
62
|
-
},
|
63
|
-
})
|
64
|
-
.option("timeout", {
|
65
|
-
alias: "t",
|
66
|
-
type: "number",
|
67
|
-
description: "The timeout for each request in milliseconds",
|
68
|
-
default: 5000,
|
69
|
-
coerce: (timeout) => {
|
70
|
-
if (timeout < 0 || timeout > 25000) {
|
71
|
-
throw new Error("Timeout must be between 0 and 25,000 ms");
|
72
|
-
}
|
73
|
-
return timeout;
|
74
|
-
},
|
75
|
-
})
|
76
|
-
.option("retries", {
|
77
|
-
alias: "r",
|
78
|
-
type: "number",
|
79
|
-
description: "The number of retries for each request",
|
80
|
-
default: 3,
|
81
|
-
coerce: (retries) => {
|
82
|
-
if (retries < 0 || retries > 10) {
|
83
|
-
throw new Error("Retries must be between 0 and 10");
|
84
|
-
}
|
85
|
-
return retries;
|
86
|
-
},
|
87
|
-
});
|
88
|
-
},
|
89
|
-
handler: async (args) => {
|
90
|
-
try {
|
91
|
-
const argData = args as ArgumentsCamelCase<HeaderScannerCLIOpts>;
|
92
|
-
const spiderResultsPath = path.resolve(argData.spiderResults);
|
93
|
-
|
94
|
-
// Check if the spider results file exists
|
95
|
-
if (!(await fileExists(spiderResultsPath))) {
|
96
|
-
throw new Error(
|
97
|
-
`Spider results file not found at ${spiderResultsPath}`,
|
98
|
-
);
|
99
|
-
}
|
100
|
-
|
101
|
-
const spiderResults = JSON.parse(
|
102
|
-
await fs.readFile(spiderResultsPath, "utf-8"),
|
103
|
-
);
|
104
|
-
|
105
|
-
cliLogger.info("Starting Header scan on website");
|
106
|
-
|
107
|
-
const scanner = new HeaderScanner({
|
108
|
-
spiderResults,
|
109
|
-
concurrency: argData.concurrency ?? 10,
|
110
|
-
timeout: argData.timeout ?? 5000,
|
111
|
-
retries: argData.retries ?? 3,
|
112
|
-
});
|
113
|
-
|
114
|
-
const results = await scanner.scan();
|
115
|
-
|
116
|
-
const outputPath = argData.output || getDefaultFilePath();
|
117
|
-
await fs.writeFile(outputPath, JSON.stringify(results, null, 2));
|
118
|
-
cliLogger.info(`Results successfully written to ${outputPath}`);
|
119
|
-
} catch (error) {
|
120
|
-
if (error instanceof Error) {
|
121
|
-
cliLogger.error(`Error: ${error.message}`);
|
122
|
-
}
|
123
|
-
cliLogger.error("Failed to run XSS command");
|
124
|
-
process.exit(1);
|
125
|
-
}
|
126
|
-
},
|
127
|
-
};
|
128
|
-
|
129
|
-
// Utility function to check if a file exists
|
130
|
-
const fileExists = async (filePath: string) => {
|
131
|
-
try {
|
132
|
-
await fs.access(filePath);
|
133
|
-
return true;
|
134
|
-
} catch {
|
135
|
-
return false;
|
136
|
-
}
|
137
|
-
};
|
138
|
-
|
139
|
-
// Utility function to get the default file path
|
140
|
-
const getDefaultFilePath = () => {
|
141
|
-
const resolvedDir = path.resolve("sentinel_output");
|
142
|
-
|
143
|
-
// Ensure the directory exists or create it
|
144
|
-
fs.mkdir(resolvedDir, { recursive: true }).catch((err) => {
|
145
|
-
cliLogger.error(`Failed to create directory: ${err.message}`);
|
146
|
-
process.exit(1);
|
147
|
-
});
|
148
|
-
|
149
|
-
return path.resolve(resolvedDir, `headerResults_${Date.now()}.json`);
|
150
|
-
};
|