Have you ever wondered how secure the websites you visit are? Or perhaps you've wondered if someone could access your personal data if a site is vulnerable? The world of web hacking (web hacking basics) is both frightening and fascinating. In this article, we'll explore the most common web vulnerabilities, from SQL injections to XSS. We'll discuss how to "hypothetically" hack a website (purely to understand the mechanics), look at real-world examples, and explore tools for finding flaws. And, of course, we'll touch on how to protect web applications from such attacks.

Introduction: The Relevance of Web Vulnerabilities and the OWASP Top 10
Modern websites are complex systems that process massive amounts of data. Logins, passwords, payment information, personal correspondence, and photos are all stored on servers, yet users typically don't consider whether it's safe to trust their data to a particular resource. Unfortunately, there are still people looking to hack website vulnerabilities. Attackers use every conceivable method to gain unauthorized access, and the most vulnerable points can be effectively breached without basic protection.

If you want to understand what an SQL injection example is, how an XSS attack works (what is it anyway?), or what other vulnerabilities exist, it's worth first mentioning the OWASP Top 10 – a regularly updated list of the most critical web application security risks. It includes the vulnerability categories most commonly encountered in real-world projects. OWASP (Open Web Application Security Project) is a roadmap for both those who want to learn how to attack systems and those who want to protect them.

SQL Injection: Concept and Simple Example
When we talk about typical web vulnerabilities, SQL injection immediately comes to mind. It's a classic, and it's impossible to imagine a list of serious threats without it. If you've ever developed dynamic websites and haven't paid much attention to security, you've likely left an unprotected entry point open to SQL injection.

The idea is simple: a user enters data in input fields (e.g., login and password forms, search fields, comments, and so on), and the server incorrectly validates this data and concatenates it into the final SQL query. Without security measures, an attacker can inject their own code into the query. Let's say we have a careless database query:

SELECT * FROM users WHERE username = 'ENTERED_NAME' AND password = 'ENTERED_PASSWORD';
Now imagine an evil genius entering a string like 'OR '1'='1' into the username field, and something insignificant in the password field. The resulting query would look something like this:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '12345';

Because of the OR '1'='1' part, the result will be an infinitely true statement, and the system could easily return data about all users or simply authorize the attacker. In the worst case (if the attacker still has permission to modify the database), such a vulnerability could lead to the deletion of tables – a classic example would be DROP TABLE:

'; DROP TABLE users; --
This could result in the destruction of all site data. This is often cited as an example of SQL injection in basic hacking training, and a similar demonstration has been widely disseminated in numerous articles.

XSS Attacks: Mechanics and a Simple Scenario
While SQL injection attacks the database directly, XSS (Cross-Site Scripting) is about tricking the victim's browser or the entire client data processing system. You've probably seen a real-life example of someone inserting jаvascript code into a comment field, causing other users to see a pop-up window with any content they want when the page loads. This is exactly what a basic XSS attack looks like. What does it do? First, it can steal a user's cookie, which often allows access to their session. Second, it can replace page content by embedding phishing forms.

The mechanics are simple: where the user can enter arbitrary content, the server (or client-side) does not filter out potentially dangerous characters. The classic, simplest test example is inserting a script like this:

<script>alert('XSS!');</script>
If the site displays this content back without escaping, the script will actually execute in the browser. While a pop-up alert is an innocent demonstration, in production, you can insert more complex code that, for example, sends cookies to a remote server. This means an attacker can exploit your browser.

There are several types of XSS: reflected, stored, and DOM-based. Reflected XSS occurs when a malicious script is "reflected" from the server to the page via request parameters. Stored XSS occurs when malicious code is stored on the server (for example, in article comments), and when the page loads, all visitors unknowingly execute the malicious code. DOM-based XSS is a special case where the jаvascript code on the page itself insecurely processes data from the URL or other sources, resulting in a vulnerability.

Other Common Bugs (CSRF, LFI/RFI, Upload Vulnerabilities)

CSRF (Cross-Site Request Forgery)
CSRF occurs when a user, while logged in to a website, navigates to or loads a page on another resource, where a request is sent in their name to the original website. If the website doesn't verify the authenticity of the request (for example, via a token), the results can be disastrous. Imagine you're a web forum administrator and, as such, click a hidden link. Suddenly, a command is sent from your account to delete a user or even shut down the forum. That's CSRF.

LFI/RFI (Local File Inclusion / Remote File Inclusion)
These vulnerabilities are related to file inclusion mechanisms at the server level. If a script (say, in PHP) dynamically includes files based on user input and doesn't filter the path, an attacker can substitute the path to system files (LFI), exfiltrating sensitive information. In the case of an RFI, it's possible to upload a remote file containing malicious code and execute it on the server. This vulnerability was more common in older versions of engines and plugins, but sometimes it crops up in modern systems if the developer neglects secure path handling.

Upload Vulnerabilities
Many websites allow you to upload photos, documents, and so on. If you don't restrict file types or check their contents, there's a risk that an executable script (PHP, Python, Perl) or other malicious file will be uploaded instead of a harmless JPEG. As a result, an attacker can gain virtually complete access to the server by running the uploaded file directly.

Web Hole Scanning Tools: Burp Suite, SQLMap, and Others
Now that you've covered the basic vulnerabilities, it's interesting to see what tools specialists use to find and exploit vulnerabilities. Or, for those curious, who want to understand web hacking basics in practice. There are a multitude of options, but here are a few must-have tools:

Burp Suite. One of the most popular tools for web application security testing. It allows you to intercept and modify requests on the fly, select parameters, and automatically scan your site for vulnerabilities. The free version has scanning speed limitations, but is perfect for learning.
sqlmap. A specialized tool for SQL injections. It scans your site and attempts to implement various injection variants. It can automate vulnerability detection, extract databases, tables, and more. You can even try sqlmap on your own local projects to test their security.
Nmap. Not only for websites, but for the entire network. It allows you to scan ports, detect operating systems, service versions, and more. It can also be useful for web research.
OWASP ZAP (Zed Attack Proxy). The official OWASP tool for comprehensive security testing, similar in many ways to Burp Suite. Excellent for detecting XSS, SQL injections, CSRF, and other common vulnerabilities.
All these tools should be used wisely and always within the framework of legal procedures (for example, testing your own website or websites for which you have permission to perform penetration testing). Otherwise, you risk being labeled a "criminal," which can have very unpleasant consequences.

How developers can protect themselves: input validation, CSP, and other measures
As you can see, vulnerabilities are a dime a dozen. The logical question is, "Okay, so how can we protect ourselves?" Surprisingly, most problems are easily solved by establishing good practices from the start. Professional developers follow the principles of "secure development," but even beginners should know these basics.

Data validation and escaping. First and foremost, validate all input data. For SQL, use parameterized (prepared) queries and ORM, which reduce the likelihood of injection attacks. For HTML output, escape special characters (<, >, ", ', &). Any user-supplied string should be unsafe by default, meaning it should be sanitized or encoded.
XSS protection. In addition to escaping user input, a good way is to configure Content Security Policy (CSP). This is an HTTP header that tells the browser which sources of scripts, styles, images, etc. can be loaded. CSP can significantly reduce the risk of a successful XSS attack.
CSRF tokens. For forms and requests that change state (e.g., sending a message, deleting a record, etc.), use special unique tokens. These should be stored in the session and transmitted along with the form. The browser will not automatically supply the correct token for another site, so attacks like "click a link and your account will be deleted" will be blocked.
Privilege restrictions and the principle of least privilege. On the server, and even in the database, there is no need to grant full rights to everyone. For example, a database user, An account that simply reads data doesn't necessarily need to be able to delete tables. If an attacker gains access to such an account, they can cause less damage.
Update and Monitor. Keep up with framework, module, and library updates. Almost all systems periodically have vulnerabilities that are patched. Regular log monitoring and the use of IDS/IPS systems will help detect suspicious activity early.
Furthermore, it is recommended to conduct periodic security audits, engage external pentesters, and, for your own monitoring, set up at least a basic alerting system for critical events.