Premise
Programming beginner(2~Three months)Summarizes what he learned.
It may not work in the actual field or may contain incorrect content.
I would appreciate it if you could add and point out any mistakes or shallow parts.
We have summarized what we have learned about security attacks using sessions.
A session is a mechanism for temporarily storing data. This temporary storage destination is called a cookie. If you access youtube or twitter from the same terminal, you will be logged in with your own account. That is because the login information is temporarily stored in the cookie by a mechanism called a session, so you are logged in without logging in every time. An attack targeting a cookie that temporarily stores this login information is called session hijacking.
This is an attack method that uses XSS etc. to acquire a session of a regular user who is not a regular user.
In XSS, when you open a web application or web page, a script is activated and personal information is sent to the attacker. The articles summarized before are as follows. https://qiita.com/Nako4/items/845da2ed4872524c2a15
The cookie is stored using an identification number called the session ID. By stealing this session ID, session hijacking is established. ** Session ID ** Unique identification information given to legitimate users during communication
I think you can somehow guess the danger. If the session is acquired by a malicious attacker, the login information will be passed to a third party, and the legitimate user will be able to do everything he can. For example, if you have registered the delivery address and purchase information (credit card number) ・ You can see the personal information of regular users ・ Purchase goods without permission ・ You can send money ・ Send spoofed emails using your email address In this way, the damage to regular users will be very large.
There are three specific ways to attack a session. ・ Guessing the session ID ・ Stealing session ID -Force session ID
Problems with the session ID generation rules used in web applications make it easier for third parties to predict the session ID. Problematic session ID ・ User ID and email address ・ Remote IP address ・ Date and time Inferring the session ID is a method performed using a value that can be referenced from the outside. ** Countermeasure ** It does not generate its own session ID. In order not to generate a guessable session ID, it is safe to use a web application development tool such as a framework without creating a unique generation mechanism. This is because if a vulnerability is found in the session management function, it can be expected to be quickly pointed out and improved. Ruby on Rails is also one of these application development tools.
In JavaScript,
<script>document.cookie</script>
With the script You can display cookie information. If you modify this script to send the information of the legitimate user's cookie to the attacking server, session hijacking will be established. Insufficient security measures in the Internet environment may cause the session ID to be intentionally or accidentally received by a third party when communicating between a legitimate user and the server.
** Countermeasure ** ・ Prevent XSS -Use a secure internet environment. To improve the security of the Internet environment, we use a mechanism to encrypt communications on the Internet. This encryption mechanism is called SSL.
SSL(Secure Sockets Layer) SSL is a technology that encrypts communication on the Internet. By encrypting and communicating, it is possible to prevent eavesdropping and falsification of information from a third party. By using this SSL, you can keep it secure when exchanging common information such as cookies. SSL-enabled URLs are web pages that start with https: //.
This is a method for the attacker to forcibly fix the session from the face. The specific procedure is (1) Attacker obtains session ID (abc) as a legitimate user (2) Force the session ID obtained in (1) to the regular user ③ Regular users log in to the target application ④ The attacker accesses the target application using the session ID (abc) forced by the legitimate user.
Sessions were used to maintain the state of the user. For legitimate users, the state in which authentication such as login is completed in the session forced by the attacker is temporarily saved. In other words, this session can also be used by an attacker to access the logged-in page. ** Countermeasure ** Change session ID after login There are many different ways to fix a session ID, so it's important to keep changing it so it doesn't get fixed. For example, if you change the session ID immediately after logging in, even if the session is forced, it will be updated after login, so you cannot use the web application using the session forced by the attacker. Devise, one of the Ruby on Rails gems, uses this mechanism.
A session is a mechanism that allows you to temporarily store login information and is stored in a place called a cookie. There are three types of security attacks using sessions: guessing, stealing, and forcing. Guess: Using an existing framework without creating your own production rules makes it harder to guess the session ID. Stealing: Take basic XSS countermeasures. Forced: Prevents the session ID from being fixed by changing the session ID after login.
Recommended Posts