Session Management and Insecure Deserialization

What are the potential problems with the approach of creating a session ID by concatenating user_id and time?

• Session ID is too long

• Does not utilize hashing

• Can be predicted by an attacker

• Uses time function too frequently

What is the main vulnerability of storing session tokens in cookies as shown?

• Session fixation

• XSS

• Lack of HttpOnly and Secure

• SQL Injection

What is the main risk if session timeout is set too long (e.g., 24 hours)?

• Application crash

• Too frequent logouts

• Increased potential for session hijacking

• Issues with database indexing

What is the main protection against session hijacking when users are on public networks?

• Using a special port

• Adding captcha

• Enabling Secure and HttpOnly on cookies

• Storing session in URL

Why is storing session tokens in localStorage considered risky?

• Tokens can be lost after refresh

• Cannot be read by the server

• Vulnerable to XSS

• Not compatible with all browsers

What type of attack is the code 'document.cookie = "sessionid=123abc";' vulnerable to?

• CSRF

• Clickjacking

• XSS

• Deserialization

What is the best practice when a user logs out of an application?

• Remove token from client only

• Remove session from server and client

• Delete cookie with script

• Disable session timeout

Which of the following is NOT a method to mitigate session fixation?

• Regenerate session ID after login

• Store session in URL

• Avoid reuse of session ID

• Use cookies with Secure flag

What is the main drawback of the logout approach shown in the code?

• Does not redirect correctly

• Does not remove session from server

• Too simplistic

• No user check

If someone successfully steals a session ID, but the client's IP address is different, what security mechanism can be used?

• Rate limiting

• IP binding on session

• Additional captcha

• No solution