[RUBY] Vulnerabilities and Countermeasures in Important Processing (Purchase Processing) (CSRF)

Premise
Programming beginner(2~Three months)Is what I learned.
It may contain things that do not work in the actual field or that are wrong.
We would appreciate it if you could point out or add any points that are incorrect or that you do not understand.

We have summarized one of the attacks against important processing, CSRF (Cross-Site Request Forgery). What is important processing, for example? It is a process that should not be executed from the outside, such as posting on a bulletin board, sending an email, or purchasing a product on an EC site. In CSRF, this important process is used by an attacker to impersonate a legitimate user (send a request).

CSRF mechanism and countermeasures

** What exactly will CSRF do? ** The following important processes exist in the Web application. ・ Payment by credit card ・ Send email ·change Password An attacker can use these important processes by impersonating a legitimate user.

CSRF (Cross Site Request Forgery)

An attack in which an attacker steals a user's login information (session hijacking) and sends a request to a vulnerable web application by impersonating a legitimate user. A spoofing request is a malicious request, and a web application that cannot determine this malicious request is vulnerable to CSRF.

Damage that can occur if there is a CSRF vulnerability

The CSRF vulnerabilities can cause the following damages: ・ User account is misused ・ The user's password and email address will be changed. ・ The money that the user has is used

How CSRF works

Procedure for CSRF ① Prepare a website where an attacker steals user information An attacker creates a website in advance to steal information (for session hijacking). (2) The user logs in on the vulnerable Web application and obtains the session ID. Log in to the vulnerable web application to use the website as usual. ③ Access a malicious site while logged in to the Web application By accessing a malicious website from a vulnerable website, session hijacking is established and the login information is stolen by an attacker. (4) Make an unauthorized request to a vulnerable Web application based on the login information extracted by the attacker. An attacker uses the login information stolen by session hijacking to impersonate a legitimate user and make fraudulent requests (such as purchasing goods or sending money).

A vulnerable web application cannot determine whether this malicious request is malicious or not. In this way, CSRF is established. By the way, XSS is a client-side vulnerability and CSRF is a server-side vulnerability.

CSRF measures

Identifying items that should be taken against CSRF

First of all, it is important to know the request that needs to take CSRF measures. CSRF does not have to be done for every request. Requests that require countermeasures are requests that should not be executed by other users. For example, requests such as EC site purchase processing and password change processing.

Specific countermeasures

There are two effective ways to determine if the request is from a legitimate user. ・ Enter password before confirmation -Embedding tokens in requests

Countermeasure ① Re-enter password

Ask them to enter their password again before the important process is confirmed. It is possible to prevent CSRF attacks by having the current password entered for requests related to password changes that are the targets of CSRF attacks. Although the attacker is logged in by session hijacking, this method can be used because the password itself is not known.

Countermeasure (2) Embedding token (confidential information) in the request

If the attacker requests a token that the attacker does not know for pages that require CSRF countermeasures such as the registration screen and order confirmation screen, important processing due to fraudulent requests will not be executed.

token A token is a password that can be used only once and is stored only on the user's browser. It is often used for user authentication. When you perform processing such as login, a unique token is saved in the sender's browser. When other users make similar requests, the tokens are different or do not exist. In this way, you can determine whether the request is invalid. By the way, this measure is taken in the helper method which is a form of Ruby on Rails.

Finally

important point As some of you may have noticed, the existence of XSS and session hijacking vulnerabilities could even extract this token. As a result, CSRF measures become meaningless. In other words ** Security measures need to be comprehensive in all aspects ** about it. Even if you strengthen one place, there is a possibility that another weak place will give you a clue to break through the strengthened one place.

Recommended Posts

Vulnerabilities and Countermeasures in Important Processing (Purchase Processing) (CSRF)
Parallel and parallel processing in various languages (Java edition)
[Android / Java] Screen transition and return processing in fragments
Asynchronous processing and Web API integration in Android Studio