CST 438 - Week 6

Security Vulnerabilities

This week I learned more about web-based security vulnerabilities. Some I was already familiar with, like SQL injection and DoS attacks. Others I either had not heard about or did not understand the technical details, like CSRF, XSS, and CORS. 

• CSRF (Cross-site Request Forgery) attacks allow attackers to send data to a website that you are already logged into. If the legitimate site relies only on session cookies for validation of user requests, it is possible for a malicious site (that you happen to visit) to take advantage and make HTTP requests using those session cookies. This may result in passwords being changed or information being stolen. One way to mitigate this attack is for the legitimate website to include a CSRF token with all requests. Tokens should be unpredictable and tied to a user's session. If the token is invalid or missing, the request is rejected.
• XSS (Cross-site Scripting) attacks allow attackers to "trick" web servers into returning malicious JavaScript code to their users. This can happen if user input is not properly filtered. For instance, if a website stores user input in a database for later viewing by other users (such as a car sale listing website), a malicious user could include <script src="..."> in their listing which would then be delivered to other users who view the listing, resulting in their browser running the malicious script. Attackers can use this to steal session information and impersonate a legitimate user, potentially stealing sensitive data like credit card information. One way for websites to mitigate this is to prevent users from including angle brackets in their input by replacing them with &lt and &gt, respectively.
• CORS (Cross-origin Resource Sharing) is a policy that allows web servers to request resources from other web servers outside their domain. For example, website foo.com may need to request a resource from bar.com (like an image file). However, web browsers do not automatically allow cross-origin requests due to their same-origin policy. This means that web servers must explicitly allow requests from outside their domain. If a web server implements its COR policy improperly (e.g., using wildcards in whitelisted domains) or makes it too lax (allowing requests from any domain), attackers can take advantage. 

OAuth 2.0 Message Flow

I also learned about OAuth 2.0, an authentication protocol that allows clients to access resources from web servers on behalf of a user. An example message flow is as follows. A client sends a login request to a web server which redirects the user to an authorization server (e.g., Google). The user enters their credentials, and the authorization server authenticates the client. The authorization server returns an access token to the client which is redirected back to the web server. The web server uses the access token to obtain information about the user from the authorization server (e.g., Google profile information) and informs the client that login was successful.