Security of network applications Flashcards

Question

HTTP security

Answer 1

* HTTP/1.0 defines 2 security mechanisms: * **address-based**: access control based on IP of client (ipspoofing =\> useless) * **password-based**: access control based on username and password (in clear (Base64) =\> sniffable) * HTTP/1.1 introduced **digest-authentication** based on **symmetric challenge** response protocol (RFC-2617) HTTP **realm**: suggestion that will be displayed in a pop-up message to suggest to the client which username and password should be used.

Answer 2

Implicit challenge, response must use a password. Keyed-digest computation: * The browser: HA1 = md5(A1) = md5(user “:” realm “:” pwd) * The browser: HA2 = md5(A2) = md5(method “:” URL) * The browser sends to server: Response = md5(HA1 “:” nonce “:” HA2) * Server uses a nonce to avoid replay attacks * The authentication server may insert a field “opaque” to transport state information (e.g. a SAML token) towards the content server. In the picture the server asks for digest authentication after refusing to the request.

Answer 3

* TLS then HTTP (RFC HTTP over TLS) * HTTP then TLS (RFC TLS within HTTP/1.1) * SSL then HTTP is widespread but undocumented. Both approches give equivalent security, but they are not equivalent in the way they impact applications, firewalls and IDSs architectures: * **Applications:** * TLS then HTTP * Changes nothing for the application developers. * TLS is always on, even for pages that don't need it. * HTTP then TLS * Developer has the option to decide where/when to activate TLS. * Must be cautios and aware of TLS. * **Firewalls:** * TLS then HTTP * there are 2 ports 80 and 443/HTTP over TLS, firewall can easily distinguish the traffic: 80 -\> clear, 443 -\> encrypted. * HTTP then TLS: * traffic can't be checked, it's all unprodected traffic, that will be left like this or encrypted later, on rules decided by developer. * Firewall is not anymore in charge of selecting only secure channels. * **IDSs:** * TLS then HTTP * IDS is not able to inspect HTTPS traffic since it is encrypted. * can look at the initial part and see when the channel is turned to a secure one. * HTTP then TLS: can inspect everything.

Answer 4

The **earlier** the **authn** the smaller the **attack surface**: * TLS authentication: only TLS library bugs can be exploited for attacks. * HTTP authn: the above + HTTP web server bugs (big piece of SW -\> potentially more bugs) * Application authentication: above + application bugs Automatic application authn It is possible to identify the user that opened a channel (without asking for user/pass). Possible through a semi-automatic mapping between credentails extracted from **X.509 certificate** and the users of HTTP service and/or OS, so that when authentication is performed at transport level, it is also recognized at application level.

Answer 5

Not really, it's only important that the action of the form is towards a rule that is TLS-protected ( ). Altough if the page is not protected, users might trust fake pages that are not SSL protected (phishing), not many people have knowledge of examining the form action field.

Answer 6

New HTTP header: HSTS. Used by the HTTP server to declare that all its interaction with the user-agent must only be via HTTPs. Features: * prevents protocol downgrade and cookie hijacking * it is valid only in HTTPs response * may include subdomains(recommended0 * May be pre-loaded (browsers may have already knowledge that when a certain domain is contacted TLS must be used): * dangerous because if HTTPS fails there is no possibility to contact server * Preloaded list maintained by Google and used by many web browsers.

Answer 7

* HPKP: To avoid the creation of fake certs for a website by malicious actors, the manager of the website can insert in the header the **hash of the public key** that is using and the UA (browser) **caches the key** and will **refuse** to connect to a site with a **different key**, even when presented with a valid certificate. * This is a TOFU (Trust on First Use) technique that can be dangerous when losing control of the key or when it must be updated * **always include a backup/secondary key** * Modes: * Enforcing: connection is closed if key is different. * Report-only: if different key -\> the connection proceeds, but it is reported to the user and the server.

Answer 8

* why? * failure of digital cash, technically and politically (e.g. DigiCash) * Failure of a dedicated payment protocol (SET, Secure Electronic Transactions): technical and organizational issues. * Most widely used approach is transmitting credit card number over TLS channel * no guarantee against fraud, since most credit card numbers are stolen offline. On the internet it's very easy to spend money from stole credit cards, on the other hand. *

Answer 9

* The merchant should not be asking about the payment data (too risky) * Should use **payment gateway** * PG creates a secure channel where credit card data is sent. * PG creates a virtual POS that uses to create a transaction valid for the payment network, that checks if the data is valid. * Upon receiving a positive response from the payment network, the PG replies to the merchant that everything went fine.] * The buyer owns a credit cast adn a TLS-enable browser. * Effective security depends on the security level of both the server and the client. * The merchant doens't know anything about the payment information, which is good, drawback: PG could profile the merchant (know data about its sales). * If merchant wants to rely on its own architecture to perform the payment, it should comply with **PCI DSS.**

Answer 10

Payment Card Industry Data Security Standard, and it is required by all credit card issuers for Internet-based transactions. It is very detailed set of technical prescriptions compared to other security standards (e.g. HIPAA = Health Insurance Portability and Accountability Act). Complex, so company prefer to rely on PG. **design, build and operate a protected network:** * R1 = install and maintain a configuration with firewall to protect **access to the cardholders’ data** * R2 = don’t use pre-defined system passwords or other security parameters set by the manufacturer * protect the cardholders’ data: * R3 = protect the stored cardholders’ data * R4 = encrypt the cardholders’ data when transmitted across an open public network **establish and follow a program for vulnerability management** * R5 = use an antivirus and regularly update it * R6 = develop and maintain protected applications and systems * implement strong access control * R7 = limit the access to the cardholders’ data only to those **needed for a specific task** * R8 = assign a single unique ID to each user * R9 = limit physical access to the cardholders’ data **regularly monitor and test the networks** * R10 = monitor and track all accesses to network resources and cardholders’ data * R11 = periodically test the protection systems and procedures **adopt a Security Policy** * R12 = adopt a Security Policy