8. HTTP and World Wide Web (WWW) Security Flashcards
(15 cards)
Why is HTTP described as a stateless protocol, and what technology is commonly used to address this limitation on the World Wide Web?
HTTP is a stateless protocol because the server does not inherently remember previous client requests. A client requests a page, and the server sends it; if the client requests a second page later, the server has no built-to-protocol way of knowing it’s the same user who made the first request.
Being stateless simplifies HTTP but limits its application. To add state information for clients, the technology commonly used is HTTP Cookies.
According to the sources, how are HTTP Cookies used to maintain state information on the World Wide Web?
According to the sources, HTTP Cookies are used for:
* Authentication: Storing user IDs and passwords (often in encoded form), so a user doesn’t need to log in on subsequent visits
* Personalization: Remembering user preferences (e.g., for fonts, colors, site options).
* Shopping carts: Tracking items a user has added to a virtual shopping cart.
* Tracking: Monitoring how a site is used, including multi-site tracking by companies to build user profiles.
Cookies work as a small piece of text made by the server and sent to the browser, which then stores it and sends it back to the server with every new page request. A cookie is typically a name-value pair
What are some security and privacy issues related to using HTTP Cookies?
Several security and privacy issues are associated with HTTP Cookies:
* Security:
◦ Users can change cookies before continuing to browse.
◦ Users could swap or steal cookies.
◦ Session Hijacking is a risk.
◦ Poorly designed sites might store sensitive information like credit card numbers directly in the cookie, which is insecure.
* Privacy:
◦ Servers can remember a user’s previous actions.
◦ If personal information is given, servers can link it to past actions recorded in the cookie.
◦ Servers can share cookie information with cooperating third parties, enabling cross-site tracking.
What is a Cross-Site Scripting (XSS) attack?
A Cross-Site Scripting (XSS) attack occurs when an attacker injects a malicious script into a webpage viewed by a victim user.
According to the sources, what are the two main types of Cross-Site Scripting (XSS) attacks? Briefly explain each.
The two main types of XSS attacks mentioned are:
- Non-persistent (or reflected) XSS: The attacker gets the victim user to click on a specially-crafted URL that includes scripts within it, often delivered via email. The malicious script is reflected off the server back to the user’s browser and executed.
- Persistent (or stored) XSS: The attacker injects the malicious script directly into the victim’s server (e.g., through forum posts, blog comments, or feedback forms). The script is stored on the server and loaded together with the normal webpage content when other users view the page.
How can Cross-Site Scripting (XSS) attacks be prevented?
To prevent XSS attacks, the sources suggest several methods:
- Input validation: Check that inputs are of the expected type. This can include HTML sanitization to remove potentially dangerous tags like
, <object>, and <link></link>.</object>
- Output escaping: Escape dynamic data before inserting it into HTML. This converts characters like < and > into their HTML entity equivalents (< and >) so they are rendered as text instead of being interpreted as code.
- Cookie security: Implement measures to protect cookies. (Though specific measures are not detailed here, it’s listed as a prevention method).
- Disable scripts: Scripts can be disabled in the browser, although this may break website functionality.
What is a SQL Injection attack, and how can it be protected against?
A SQL Injection attack involves placing malicious code into SQL statements via web page input fields.
This can trick the database into executing unintended commands, such as retrieving all user records (e.g., by inputting 1050 OR 1=1 into a UserID field).
Protection against SQL injection can be achieved by using SQL parameters. This separates the SQL code from the user-provided data, preventing the input from being interpreted as part of the command.
What are the security risks associated with standard HTTP Basic Authentication?
Standard HTTP Basic Authentication has several security risks:
- Username and password credentials are sent encoded, not encrypted. Base64 encoding tools are readily available, meaning the credentials are easy to read if intercepted.
- The authentication information is sent with every request and does not change between different requests, making it vulnerable to sniffers who can replay the request.
- Requesting unnecessary authentication can lead to users sharing passwords.
- Basic authentication only authenticates the browser (user), not the server, meaning impersonating websites could harvest passwords without the user being able to easily verify the server’s identity.
HTTP Digest Authentication avoids some of these flaws but does not provide server authentication and is vulnerable to Man-in-the-Middle (MITM) attacks.
What is HTTPS, and how does it secure web communication compared to HTTP?
HTTPS stands for HTTP over TLS (or HTTP over SSL).
It adds the security capabilities of SSL/TLS to standard HTTP by layering HTTP on top of the SSL or TLS protocol.
This layering provides three essential security services for web communication:
* Encryption: Ensures only authorized parties can understand the message contents.
* Authentication: Verifies the identity of the server (and optionally the client).
* Data Integrity: Detects if the message has been tampered with or forged during transit.
How can a user typically tell if a website is using HTTPS and encryption?
Users can identify if a website is using HTTPS by:
* Observing a closed padlock icon in the web browser’s address bar.
* Checking that the URL in the address bar begins with “https:” rather than “http:”.
HTTPS also uses port 443 by default, whereas standard HTTP uses port 80 by default.
In the context of securing web communication (like HTTPS), what is a Digital Certificate, and what role does a Certificate Authority (CA) play?
A Digital Certificate is used to guarantee that you are communicating with the legitimate partner you intend to.
A Certificate Authority (CA) is a trusted entity responsible for generating, signing, and managing these certificates. When a certificate is needed (e.g., for a server), the CA generates it and signs it using its own private key.
The CA’s public key is often stored locally by web browsers as a trusted root.
Suppose Bob has a certificate Cbob from a Certificate Authority (CA). When Alice wants to authenticate Bob (as described in Lecture 16), Bob presents Cbob to Alice. Describe the rest of the procedure.
Following Bob presenting his certificate Cbob to Alice:
1.Alice uses the CA’s public key (which she trusts and likely has stored locally) to verify the signature on Bob’s certificate (Cbob).
2. If the signature is valid, Alice knows the certificate was indeed issued by that trusted CA and has not been tampered with. She then extracts Bob’s public key from the certificate.
3. Alice can now authenticate Bob using the extracted public key, typically as part of the SSL/TLS handshake process. This often involves a challenge-response mechanism where Alice sends a nonce (random number) encrypted with Bob’s public key, and Bob must decrypt it and prove he knows the original nonce (using his private key).
What factors should one check to determine if a digital certificate can be trusted?
To trust a digital certificate, you should check:
* If the web address (URL) matches the address specified on the certificate.
* If the certificate is signed by a trusted certificate authority and if the date is valid (within its validity period).
* Other technical details like the key length, extensions, and encryption algorithms used.
Besides encryption and authentication, what other essential service does SSL/TLS provide?
In addition to encryption and authentication, SSL/TLS also provides Data Integrity.
This service ensures that the message transmitted has not been altered or forged during transit without detection.
Message digests are used for this purpose
Briefly describe the overall goal of the SSL/TLS Handshake Protocol phases.
The Handshake Protocol is a part of SSL/TLS that uses messages to:
* Negotiate the cipher suite to be used.
* Authenticate the server and/or client (using certificates).
* Exchange information (like random numbers and a pre-master secret) needed for building cryptographic secrets (session keys).
This process involves phases where client and server establish security capabilities, perform authentication and key exchange, and finalize the handshake before application data is transmitted securely.
