This post was last updated on January 7th, 2023 at 05:33 pm
This post will address some factors or elements that affect web security. Your knowledge of these would go a long way in preparing you to combat any attack that may be targeted at you from the websites. Once your business grows, you can learn more about topics like identity and access management, but that’s more relevant to enterprise-level organizations. Here is a summary of the basics of web security you must know. Without further delay, let’s get into it.
1. The Basics of Web Security you must Know: SQL injection
Definition of SQL Injection
By definition, SQL injection is a code injection technique that might destroy your database. In a simpler form, SQL injection is the placement of malicious code in SQL statements, via web page input.
Since the user input is not checked strictly in the program, the user can submit a piece of database query code, and obtain some data he wants to know based on the results returned by the program. This is the so-called SQL Injection.
Must Read: How to Improve Security on Your Mobile Device
Its essence is that the input check is not sufficient. This in turn causes the SQL statement to execute the illegal data submitted by the user as part of the statement.
Because some of our WEB applications use Jsp JavaBean or SSH framework, there will be direct SQL (or HQL) statements written in the code, and some SQL is implemented by spelling.
Risk Associated with SQL Injection:
- Blind SQL Note: If the system blocks detailed error messages, it is a blind injection to the attacker, and may view, modify, or delete database entries and tables.
- Authentication bypass using SQL injection: The authentication mechanism of the Web application may be bypassed.
Remarks About SQL Injection Vulnerability
- First off, it is not a vulnerability in the database, neither is it a vulnerability in a web service program or script interpreter.
- Secondly, It is a bug in the application itself and a problem caused by the development of the website program.
How to Prevent SQL injection
- Firstly, never trust user input. To verify the user’s input, you can use regular expressions, or limit the length; convert single quotes and double “-“, etc.
- Secondly, never use dynamic assembly SQL. Instead, you can use parameterized SQL or directly use stored procedures for data query access.
- Thirdly, never use a database connection with administrator privileges. Use a separate database connection with limited privileges for each application.
- Furthermore. do not store confidential information directly, encrypt, or hash out passwords and sensitive information.
- The exception information of the application should give a few hints as possible, and it is best to use custom error information to wrap the original error information.
- Use some tools or network platforms to detect SQL injection.
2. Cross-site Scripting Vulnerability (XSS)
Cross-site Scripting refers to a malicious attacker inserting malicious HTML code into a Web page. When the user browses the page, the HTML code embedded in the Web will be executed, thereby achieving the special purpose of the malicious user.
This type of attack generally does not pose any threat to the website host itself. Attackers use certain languages to use the website host as a springboard to attack website users.
Especially Relevant: How To Secure/Protect Your SmartPhones Against Attacks From Virus,Hackers or Theft
Classification of XSS
Persistent XSS, in contrast to non-persistent XSS, refers to the submission of malicious data to the server and the output of malicious data to the page through web applications.
Persistent XSS mostly appears in Web mailboxes, bulletin board system, communities, etc. from databases A normal page for reading data (for example, a BBS post may contain malicious code)
Non-persistent XSS (Non-persistent), or reflection, refers to cross-site scripting vulnerabilities that browsers must submit malicious data in the parameters every time to trigger.
How to Prevent XSS Cross-site Scripting Attacks
- Principle: Do not trust the data entered by the user Note: The attack code may not be in
- Only allow users to enter the data we expect. For example: in the textbox of age, only the user is allowed to enter numbers, and characters other than that, numbers are filtered out.
- Filter or remove special Html tags. For example:,,, “for.
3. Cross-site Request Forgery XSRF
XSRF/CSRF Attack Process
As can be seen from the above figure, to complete a CSRF attack, the victim must complete two steps in sequence:
- Log in to trusted website A and generate a cookie locally.
- Visit the dangerous website B without logging out of A.
Seeing this, you may say: “If I do not meet one of the above two conditions, I will not be attacked by CSRF”. Yes, it is true, but you cannot guarantee that the following will not happen:
- You cannot guarantee that after logging in to a website, you will not open a tab page and visit another website.
- Secondly, you cannot guarantee that after you close the browser, your local cookies will expire immediately and your last session has ended. (In fact, closing the browser cannot end a session, but most people mistakenly believe that closing the browser is equivalent to logging out/ending the session…)
- Moreover, the so-called attack website in the above picture may be a trusted website that has other vulnerabilities and is frequently visited by people.
The difference between CSRF and XSS
XSS: The malicious script is echoed to the user’s browser for execution through the server.
CSRF on the other hand can be a malicious script, or it may be a malicious HTML tag; it may be echoed by the server, or it may not be passed at all) causing the browser to initiate an offensive request.
Tips on How to Prevent CSRF Cross-Site Request Forgery
- For web sites, switch the persistent authorization method (such as cookie or HTTP authorization) to an instantaneous authorization method (a hidden field is provided in each form).
- Use the Post instead of getting. The Post method will not leave a data tail in the web server and proxy server logs, but the Get method will leave a data trail.
4. File Upload Vulnerabilities: Common Verification Errors
- This web security issue allows the upload of executable files
- Use client JS to verify the uploaded file type
- Use the blacklist to restrict upload file types
- Filename/storage directory name can be customized
- It allows improper handling of special characters in filenames
File upload vulnerability solution:
- First of all, the encoder needs to strictly control the upload page code, especially when saving the file. You need to check the possibilities of abnormal characters, such as ../, ..\, empty characters, etc.
- Secondly, to check the file extension, it is necessary to adopt the check such as “allow jpg, gif…” instead of the check such as “not allow asp…”;
5. “File Contains Vulnerabilities”
The file contains vulnerabilities. If the client user input is allowed to control the files dynamically included on the server-side, it will lead to the execution of malicious code and the disclosure of sensitive information.
The Solution to File Contain Vulnerabilities Exploit:
- Strictly check whether the variable has been initialized.
It is recommended to assume that all inputs are suspicious, and try to perform strict checks on all file addresses that may be included in the input submission, including server local files and remote files, and directory jump characters such as ../ are not allowed in the parameters.
- Strictly check whether the parameters in the include function are controlled by the outside world.
Don’t just verify and filter data on the client-side, the key filtering steps are performed on the server-side.
- Lastly, test all known threats before releasing the application.
6. Cookie Safety Attack
The user’s cookie may be stolen by an attacker for some reason, and the attacker may use the stolen cookie to log in to the user’s website directly as the user.
7. Directory Traversal Attack
Refers to attackers using application vulnerabilities to access data or file directories outside of legitimate applications, resulting in data leakage or tampering.
The most common is to use the “double period on behalf of the parent directory” mechanism to attack. For example: “../../../../../../etc/passwd”
The web server mainly provides two levels of security mechanisms
Root directory access: A specific directory in the server file system serves as the root directory of the website. It is often a restriction, and users cannot access any content located above this directory.
Access control list (ACL): A list used by the administrator of the Web server to specify what users or user groups can access, modify, and execute certain files on the server.
8. Distributed Denial of Service Attack
DDoS attack uses inherent loopholes in network protocols to forge reasonable service requests. It consumes limited network bandwidth or occupies too many service resources so that the network or service cannot respond to the normal requests of users. This attack will eventually cause network services to be paralyzed.
Types of DDoS
- Resource exhaustion types include UDP DNS Query Flood, Connection Flood, HTTP Get Flood, etc.
- Traffic types are: syn_flood, ack_flood, rst_flood, udp_flood, icmp_flood, etc.
9. Direct references to unsafe objects or Insecure Direct Object References
IDOR occurs when the developer exposes a reference to the internally deployed object of the website to the user, such as a file, directory, database key, etc., if the system does not have access control checks or other protective measures, the attacker can forge the reference to achieve unauthorized data Access.
Principle of Insecure Direct Object References
The basic attack principle is to guess the references of other unauthorized objects based on existing object references. This attack may occur when the website address or other parameters contain references such as files, directories, database records, or keywords.
Leave a Reply