├── sql-go.png
├── sql-injection-detector.go
├── LICENSE
└── README.md
/sql-go.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/R3DHULK/sqli-detector-in-golang/HEAD/sql-go.png
--------------------------------------------------------------------------------
/sql-injection-detector.go:
--------------------------------------------------------------------------------
1 | package main
2 |
3 | import (
4 | "net/http"
5 | "fmt"
6 | )
7 |
8 | func scan(url string) {
9 | // These are common SQL injection payloads
10 | payloads := []string{"' OR 1=1; --", "' OR '1'='1"}
11 |
12 | for _, payload := range payloads {
13 | resp, err := http.Get(url + payload)
14 | if err != nil {
15 | fmt.Printf("Error checking URL: %s\n", err)
16 | }
17 | if resp.StatusCode == 200 {
18 | fmt.Printf(" [*] SQL Injection Vulnerability Found In %s\n", url)
19 | break
20 | }
21 | }
22 | }
23 |
24 | func main() {
25 | // Test the scanner with a vulnerable URL
26 | scan("http://testphp.vulnweb.com/artists.php?artist=1")
27 | }
28 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2023 Sumalya Chatterjee
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
SQL Injection Detector In GoLang
2 |
3 |
4 | #
5 | What Is SQL Injection?
6 | SQL injection is a code injection technique that might destroy your database.
7 |
8 | #
9 | What is the impact of a successful SQL injection attack?
10 | There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in different situations. Some common SQL injection examples include:
11 |
12 | 💀 Retrieving hidden data, where you can modify an SQL query to return additional results.
13 | 💀 Subverting application logic, where you can change a query to interfere with the application's logic.
14 | 💀 UNION attacks, where you can retrieve data from different database tables.
15 | Examining the database, where you can extract information about the version and structure of the database.
16 | 💀 Blind SQL injection, where the results of a query you control are not returned in the application's responses.
17 |
18 |
19 |
20 | #
21 | How and Why Is an SQL Injection Attack Performed?
22 | To make an SQL Injection attack, an attacker must first find vulnerable user inputs within the web page or web application. A web page or web application that has an SQL Injection vulnerability uses such user input directly in an SQL query. The attacker can create input content. Such content is often called a malicious payload and is the key part of the attack. After the attacker sends this content, malicious SQL commands are executed in the database.
23 |
24 | SQL is a query language that was designed to manage data stored in relational databases. You can use it to access, modify, and delete data. Many web applications and websites store all the data in SQL databases. In some cases, you can also use SQL commands to run operating system commands. Therefore, a successful SQL Injection attack can have very serious consequences.
25 |
26 | 👽 Attackers can use SQL Injections to find the credentials of other users in the database. They can then impersonate these users. The impersonated user may be a database administrator with all database privileges.
27 | 👽 SQL lets you select and output data from the database. An SQL Injection vulnerability could allow the attacker to gain complete access to all data in a database server.
28 | SQL also lets you alter data in a database and add new data. For example, in a financial application, an attacker could use SQL Injection to alter balances, void transactions, or transfer money to their account.
29 | 👽 You can use SQL to delete records from a database, even drop tables. Even if the administrator makes database backups, deletion of data could affect application availability until the database is restored. Also, backups may not cover the most recent data.
30 | 👽 In some database servers, you can access the operating system using the database server. This may be intentional or accidental. In such case, an attacker could use an SQL Injection as the initial vector and then attack the internal network behind a firewall.
31 |
32 |
33 | #
34 | Simple SQL Injection Example
35 |
36 | The first example is very simple. It shows, how an attacker can use an SQL Injection vulnerability to go around application security and authenticate as the administrator.
37 |
38 | The following script is pseudocode executed on a web server. It is a simple example of authenticating with a username and a password. The example database has a table named users with the following columns: username and password.
39 |
40 | ```
41 | # Define POST variables
42 | uname = request.POST['username']
43 | passwd = request.POST['password']
44 |
45 | # SQL query vulnerable to SQLi
46 | sql = “SELECT id FROM users WHERE username=’” + uname + “’ AND password=’” + passwd + “’”
47 |
48 | # Execute the SQL statement
49 | database.execute(sql)
50 | ```
51 | These input fields are vulnerable to SQL Injection. An attacker could use SQL commands in the input in a way that would alter the SQL statement executed by the database server. For example, they could use a trick involving a single quote and set the passwd field to:
52 |
53 | ```
54 | password' OR 1=1
55 | ```
56 | Because of the OR 1=1 statement, the WHERE clause returns the first id from the users table no matter what the username and password are. The first user id in a database is very often the administrator. In this way, the attacker not only bypasses authentication but also gains administrator privileges. They can also comment out the rest of the SQL statement to control the execution of the SQL query further:
57 |
58 | ```
59 | -- MySQL, MSSQL, Oracle, PostgreSQL, SQLite
60 | ' OR '1'='1' --
61 | ' OR '1'='1' /*
62 | -- MySQL
63 | ' OR '1'='1' #
64 | -- Access (using null characters)
65 | ' OR '1'='1' %00
66 | ' OR '1'='1' %16
67 | ```
68 |
69 |
70 | #
71 | 🔴 Disclaimer : This Project Is Not For Promoting Unethical Activities.
72 | If Anyone Do Something Mistakenly, Developer Is Not Responsible For That.
73 |
74 | #
75 | Introducing My Tool 💡
76 | sqli-scanner.rb is a basic sql injection finder for you. It can go through all vulnerable urls.
77 |
78 | #
79 | Give Your Close Look Here 👇
80 |
81 | 
82 |
83 | #
84 | 👾 Git Installation
85 |
86 | ```
87 | # Required GoLang
88 |
89 | # Clone My Repository
90 | git clone https://github.com/R3DHULK/sqli-detector-in-golang
91 |
92 | # Change Directory
93 | cd sqli-detector-in-golang
94 |
95 | # Execute
96 | go run sql-injection-detector.go
97 | ```
98 |
99 | #
100 | How To Prevent This?
101 | The only sure way to prevent SQL Injection attacks is input validation and parametrized queries including prepared statements. The application code should never use the input directly. The developer must sanitize all input, not only web form inputs such as login forms. They must remove potential malicious code elements such as single quotes. It is also a good idea to turn off the visibility of database errors on your production sites. Database errors can be used with SQL Injection to gain information about your database.
102 |
103 | If you discover an SQL Injection vulnerability, for example using an Acunetix scan, you may be unable to fix it immediately. For example, the vulnerability may be in open source code. In such cases, you can use a web application firewall to sanitize your input temporarily.
104 |
105 | 🔴 Note: Now There Are Many Optional Ways To Code Backend Servers (Like Javascript Frameworks).
106 |
107 | #
108 | Show Support 👇👇👇
109 | 
110 |
--------------------------------------------------------------------------------