Injection attacks stem from a lack of strict separation between program instructions (i.e., code) and user- provided (or external) input. This allows an attacker to inject malicious code into a data snippet. SQL injection is one of the most common types of injection attack. To carry it out, an attacker provides malicious SQL statements through the application. How to prevent: Prepared statements with parameterized queries Stored procedures Input validation - blacklist validation and whitelist validation Principle of least privilege - Application accounts shouldn’t assign DBA or admin type access onto the database server. This ensures that if an application is compromised, an attacker won’t have the rights to the database through the compromised application.

Authentication is the process of ascertaining that somebody really is who he claims to be. Authorization refers to rules that determine who is allowed to do what. E.g. Adam may be authorized to create and delete databases, while Usama is only authorised to read. Or in short: Authentication = login + password (who you are) Authorization = permissions (what you are allowed to do) Also:

Authentication = Verification
Authorization = Permissions

A denial-of-service attack (DoS attack) is an attempt to make a computer resource unavailable to its intended users. Denial of service is typically accomplished by flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled. In a distributed denial-of-service attack (DDoS attack), the incoming traffic flooding the victim originates from many different sources. This effectively makes it impossible to stop the attack simply by blocking a single source.

A botnet is a number of Internet-connected devices, each of which is running one or more bots. Botnets can be used to perform distributed denial-of-service attack (DDoS attack), steal data, send spam, and allows the attacker to access the device and its connection.

Security testing can be considered most important in all type of software testing. Its main objective is to find vulnerabilities in any software (web or networking) based application and protect their data from possible attacks or intruders. As many applications contains confidential data and needs to be protected being leaked. Software testing needs to be done periodically on such applications to identify threats and to take immediate action on them.

The Vulnerability can be defined as weakness of any system through which intruders or bugs can attack on the system. If security testing has not been performed rigorously on the system then chances of vulnerabilities get increase. Time to time patches or fixes requires preventing a system from the vulnerabilities

Methodologies in Security testing are: White Box - All the information are provided to the testers.

Black Box - No information is provided to the testers and they can test the system in real world scenario. Grey Box - Partial information is with the testers and rest they have to rest on their own.

XSS can be prevented by sanitizing user input to the application. Always allowed those elements as input which is absolutely essential for that field.

robots.txt is a text file placed within the root directory of a site that tells robots (such as indexers employed by search engines) how to behave, by instructing them not to index certain paths on the website. It should not be used as a way to prevent the disclosure of private information or to hide portions of a website. Although this does prevent these sites from appearing in search engines, it does not prevent its discovery from attackers, as robots.txt is frequently used for reconnaisance.

Using robots.txt to hide certain directories is a terrible idea

User-agent: * Disallow: /secret/admin-interface

Impersonation is an act of pretending to be another person. For IT Systems impersonation means that some specific users (usually Admins) could get an access to other user's data.

A Root SSL certificate is a certificate issued by a trusted certificate authority (CA). In the SSL ecosystem, anyone can generate a signing key and sign a new certificate with that signature. However, that certificate is not considered valid unless it has been directly or indirectly signed by a trusted CA. A trusted certificate authority is an entity that has been entitled to verify that someone is effectively who it declares to be. In order for this model to work, all the participants on the game must agree on a set of CA which they trust. All operating systems and most of web browsers ship with a set of trusted CAs.

SSL Certificates are small data files that digitally bind a cryptographic key to an organization’s details. When installed on a web server, it activates the padlock and the https protocol (over port 443) and allows secure connections from a web server to a browser.

DOM-based XSS is a type of cross-site scripting which appears in DOM(Document Object Model), instead of HTML.

By using Cross Site Scripting (XSS) technique, users executed malicious scripts (also called payloads) unintentionally by clicking on untrusted links and hence, these scripts pass cookies information to attackers.

To protect web applications from forced browsing, strictly monitor access-control settings are accurate and up to date on every page and application on the site.

To mitigate SQL injection: Prepared Statements with Parameterized Queries: Always ensure that your SQL interpreter always able to differentiate between code and data. Never use dynamic queries which fail to find the difference between code and data. Instead, use static SQL query and then pass in the external input as a parameter to query. Use of Prepared Statements (with Parameterized Queries) force developer to first define all the SQL code, and then pass in each parameter to the query later. Use of Stored Procedures: Stored Procedure is like a function in C where database administrator call it whenever he/she need it. It is not completely mitigated SQL injection but definitely helps in reducing risks of SQL injection by avoiding dynamic SQL generation inside. White List Input Validation: Always use white list input validation and allow only preapproved input by the developer. Never use blacklist approach as it is less secure than whitelist approach. Escaping All User Supplied Input Enforcing Least Privilege

Access Control Violation threat arises from not flagging HTTP cookies with tokens as secure.

Session Hijacking involves the exploitation of the web session control mechanism. The attacker basically exploits vulnerable connections and steals HTTP cookies to gain unauthorized access to sensitive information/data stored in web servers. The most effective countermeasure network-level session hijacking is to pick encrypted transport protocols that enable secure connections.

Session hijacking, is the issue related to A2: 2017 – Broken Authentication. It is also called cookie hijacking. In this type of attack, there is the possibility of exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a system. This flaw comes when there is a poor randomness in session key.

A request for a resource (like an image or a font) outside of the origin is known as a cross-origin request. CORS (cross-origin resource sharing) manages cross-origin requests. CORS allows servers to specify who (i.e., which origins) can access the assets on the server, among many other things. Access-Control-Allow-Origin is an HTTP header that defines which foreign origins are allowed to access the content of pages on your domain via scripts using methods such as XMLHttpRequest. For example, if your server provides both a website and an API intended for XMLHttpRequest access on a remote websites, only the API resources should return the Access-Control-Allow-Origin header. Failure to do so will allow foreign origins to read the contents of any page on your origin.

Allow any site to read the contents of this JavaScript library, so that subresource integrity works

Access-Control-Allow-Origin: *

Content Security Policy (CSP) is an HTTP header that allows site operators fine-grained control over where resources on their site can be loaded from. The use of this header is the best method to prevent cross-site scripting (XSS) vulnerabilities. Due to the difficulty in retrofitting CSP into existing websites, CSP is mandatory for all new websites and is strongly recommended for all existing high-risk sites. The primary benefit of CSP comes from disabling the use of unsafe inline JavaScript. Inline JavaScript – either reflected or stored – means that improperly escaped user-inputs can generate code that is interpreted by the web browser as JavaScript. By using CSP to disable inline JavaScript, you can effectively eliminate almost all XSS attacks against your site.

An intrusion detection system (IDS) is a device or software application that monitors a network or systems for malicious activity or policy violations. Intrusion detection check following:

Possible attacks Any abnormal activity Auditing the system data Analysis of different collected data etc.

Cross-Site Scripting (XSS) is an attack that occurs when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. The page provided by the server when someone requests it is unaltered. Instead, an XSS attack exploits a weakness in a page that include a variable submitted in a request to show up in raw form in the response. The page is only reflecting back what was submitted in that request.

A honeypot is an information system that is configured to detect an intruder by mirroring a real production system. It appears as an ordinary service doing work, but all the data and transactions are phony. Located either in or outside the firewall, the honeypot is used to learn about an intruder's techniques as well as determine vulnerabilities in the real system. In practice, honeypots are computers which masquerade as unprotected. The honeypot records all actions and interactions with users. Since honeypots don't provide any legitimate services, all activity is unauthorized (and possibly malicious).

Cross site scripting happens when an application takes user inserted data and sends it to a web browser without proper validation and escaping.

ClickJacking is an attack that fools users into thinking they are clicking on one thing when they are actually clicking on another. The attack is possible thanks to HTML frames (iframes). Its other name, user interface (UI) redressing, better describes what is going on. Users think they are using a web page’s normal UI, but in fact there is a hidden UI in control; in other words, the UI has been redressed. When users click something they think is safe, the hidden UI performs a different action.

OWASP Top 10 (2017) security flaws include: Injection Broken Authentication and Session Management Sensitive Data Exposure

XML External Entity (XXE)
Broken Access Control
Security Misconfiguration
Cross-Site Scripting (XSS)
Insecure Deserialisation
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring

A typical PKI includes the following key elements: A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root A certificate database, which stores certificate requests and issues and revokes certificates A certificate store, which resides on a local computer as a place to store issued certificates and private keys

A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify theidentity of the other party. Without PKI, sensitive information can still be

encrypted (ensuring confidentiality) and exchanged, but there

would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.

Set-Cookie: HTTPOnly attribute can also be used to prevent XSS.

Other methods where attackers store malicious scripts (also called payloads) are discussion forums, the comment section of websites and other similar platforms. Whenever the user navigates those pages, payloads got executed and user’s cookies information automatically sends to an attacker.

By using XSS, the session id of the genuine user can be stolen by the attacker. The session id is used by the browser to identify your credentials in an application and helps you keep login till sign off from an application. An attacker can write a code to extract information from cookies which contain session id and other information. Later, same session id can be used by an attacker to browse the application on behalf of the user without actually logged in the application.

This vulnerability has been removed from OWASP Top 10 2013. Actually, this issue is related to forced browsing where a user forcibly accesses URLs which is not supposed to access by the user. The attacker may guess links and brute force techniques to find unprotected pages through this vulnerability.

Following are the mitigation techniques employed for secure applications from Sensitive data exposure: Prepare a threat model to secure data both in transit and at rest from both types of the attacker( e.g. insider

attack, external user)

Encrypt data to protect it from any type of cyber attack. Never store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data. Always implement and also ensures strong standard algorithms and strong keys are used, and proper key management is in place. Consider using FIPS 140 validated cryptographic modules. Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.

Weak Authentication and Session management can be mitigated by controls of strong authentication and session management. Such controls are as follows: Compliant with all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management). Always use simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon. Use standard practices to secure session id by cross-site scripting attack.

Authorization Bypass can be avoided by having unique usernames generated with a high degree of entropy.

Cross-site request forgeries (CSRF) are a class of attacks where unauthorized commands are transmitted to a website from a trusted user. Because they inherit the users cookies (and hence session information), they appear to be validly issued commands. Consider:

HTTP Public Key Pinning (HPKP) instructs a user agent to bind a site to specific root certificate authority, intermediate certificate authority, or end-entity public key. This prevents certificate authorities from issuing unauthorized certificates for a given domain that would nevertheless be trusted by the browsers. Maximum risk sites must enable the use of HTTP Public Key Pinning (HPKP).

Encryption, encoding and hashing are techniques used for converting the format of data. Encryption is used for changing plain text into cipher text so that only authorized entities can understand it. Encryption deals with keys which are used to encrypt and decrypt the data. These keys are used to transform a simple text into a cypher text and the vice versa. Encoding is used for changing the data into a special format which makes it usable by external processes. Unlike encryption, the intention of encoding is not related to security. The message is encoded by using an algorithm or scheme. In hashing, the data is converted to a message digest or hash, which is usually a number generated from a string of text. Hashing is not reversible as encryption and encoding. The data is converted to a message digest or hash, which is usually a number generated from a string of text. These digests are important as one can easily match the hash of sent and received messages to ensure that both are the same and no tempering is done with the data.

Security testing is to be carried out to make sure that whether the system prevents the unauthorized user to access the resource and data. Security Testing needs to cover the seven attributes of Security Testing: Authentication - Authentication is a process of identifying the person before accessing the system. It allows user to access the system information only if authentication check got passed. Authorization - Once the Authentication passed the Authorization comes in the picture to limit the user as per the permission set for the user. Confidentiality - Confidentiality is to be carried out to check if unauthorized user and less privileged users are not able to access the information. It is to check that the protection of information and resources from the users other than the authorized and authenticated. Availability - The availability of system is to check the system is available for authorized users whenever they want to use except for the maintenance window & upgrade for security patches. Integrity - Integrity is to make sure that the information received is not altered during the transit & check if correct information presented to user is as per the user groups, privileges & restrictions. Non-repudiation - Nonrepudiation is the assurance that someone cannot deny something. For security testing it is tracking who is accessing the systems and which of the requests were denied along with additional details like the Timestamp and the IP address from where the requests came from. Resilience - Resilience is to check the system is resistance to bear the attacks, this can be implemented using encryption, use OTP (One Time Password), two layer authentication or RSA key token.

Firewalls limit access between networks to prevent intrusion and do not signal an attack from inside the network. An IDS describes a suspected intrusion once it has taken place and signals an alarm. An IDS also watches for attacks that originate from within a system.

Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated. A CSRF attack tricks the victim into clicking a URL that contains a maliciously crafted, unauthorized request for a particular Web application. The user’s browser then sends this maliciously crafted request to a targeted Web application. The request also includes any credentials related to the particular website (e.g., user session cookies). If the user is in an active session with a targeted Web application, the application treats this new request as an authorized request submitted by the user. How to prevent To defeat a CSRF attack, applications need a way to determine if the HTTP request is legitimately generated via the application’s user interface. The best way to achieve this is through a CSRF token. A CSRF token is a secure random token (e.g., synchronizer token or challenge token) that is used to prevent CSRF attacks. The token needs to be unique per user session and should be of large random value to make it difficult to guess.

A penetration test (pen test), is an authorized simulated attack on a computer system, performed to evaluate the security of the system performed in a form of black box security testing. In a pen test you are trying to break into the server as many times as possible and report back on how they where able to break in. Penetration only occurs after development is complete. By contrast in it white box testing or vulnerability assessment you have full access to the source code. A vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or other malicious activity is possible.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header to a web page and giving it values to control resources the user agent is allowed to load for that page.

The option is to use Content Security Policy (CSP) and its frame-ancestors directive. This directive allows the application developer to disallow all frame use or specify where it is allowed, similar to X-Frame-Options. Possible CSP frame-ancestor settings: Content-Security-Policy: frame-ancestors 'none' Content-Security-Policy: frame-ancestors 'self' Content-Security-Policy: frame-ancestors example.com

You should strongly prefer the secure wss:// protocol over the insecure ws:// transport. Like HTTPS, WSS (WebSockets over SSL/TLS) is encrypted, thus protecting against man-in-the-middle attacks. The WebSocket protocol doesn’t handle authorization or authentication. Practically, this means that a WebSocket opened from a page behind auth doesn’t “automatically” receive any sort of auth; you need to take steps to also secure the WebSocket connection. Since you cannot customize WebSocket headers from JavaScript, you’re limited to the “implicit” auth (i.e. Basic or cookies) that’s sent from the browser. Further, it’s common to have the server that handles WebSockets be completely separate from the one handling “normal” HTTP requests. This can make shared authorization headers difficult or impossible.

You can use the Origin header as an advisory mechanism—one that helps differentiate WebSocket requests from different locations and hosts, but you shouldn’t rely on it as a source of authentication. One pattern I would use that seems to solve the WebSocket authentication problem well is a “ticket”-based authentication system. Broadly speaking, it works like this: When the client-side code decides to open a WebSocket, it contacts the HTTP server to obtain an authorization “ticket”. The server generates this ticket. It typically contains some sort of user/account ID, the IP of the client requesting the ticket, a timestamp, and any other sort of internal record keeping you might need. The server stores this ticket (i.e. in a database or cache), and also returns it to the client. The client opens the WebSocket connection, and sends along this “ticket” as part of an initial handshake. The server can then compare this ticket, check source IPs, verify that the ticket hasn’t been re-used and hasn’t expired, and do any other sort of permission checking. If all goes well, the WebSocket connection is now verified.

In computing, the Challenge-Handshake Authentication Protocol (CHAP) authenticates a user or network host to an authenticating entity. CHAP is a 3 way handshake:

1. Client Connects to the websocket server, server then sends a challenge string (random characters of random or set length) to client.
2. Client responds with the hash of the challenge + shared secret
3. Server calculates the challenge it sent and the 'shared secret' it has locally and compares the client's hash to it's own and either authenticates (adds it to approved clients) or drops the client. You can get a bit further and if the client was dropped we can add him to a blocked list with a timestamp. If the client tries to connect I check if he is in the blocked list and if his timestamp is old enough. Then continue with the CHAP auth for the client again.

A salt is a fixed-length cryptographically-strong random value that is added to the input of hash functions to create unique hashes for every input, regardless of the input not being unique. A salt makes a hash function look non-deterministic, which is good as we don't want to reveal password duplications through our hashing. The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for a dictionary attack (Using a pre-arranged listing of words, such as the entries from the English dictionary, with their computed hash, the attacker easily compares the hashes from a stolen passwords table with every hash on the list. If a match is found, the password then can be deduced).

Salting is pointless if you don't have a separate salt for each user. The point of salts is to make breaking the hashes a separate task for each user password; if the salt is the same for all of them then that's not the case.

OWASP ESAPI is short for OWASP Enterprise Security API which is voluntarily developed by OWASP community to provide free, open source, web application security control library to web developers to help them to develop a less vulnerable web application. The basic design of OWASP ESAPI includes a set of security control interfaces and for each security control, there is a reference implementation which can be implemented as the requirement of the organization.

Cross-site Scripting can be divided into three types: Stored XSS

Reflected XSS DOM-based XSS

No. MD5 is not encryption (though it may be used as part of some encryption algorithms), it is a one way hash function. Much of the original data is actually "lost" as part of the transformation. Think about this: An MD5 is always 128 bits long. That means that there are 2128 possible MD5 hashes. That is a reasonably large number, and yet it is most definitely finite. And yet, there are an infinite number of possible inputs to a given hash function (and most of them contain more than 128 bits, or a measly 16 bytes). So there are actually an infinite number of possibilities for data that would hash to the same value. The thing that makes hashes interesting is that it is incredibly difficult to find two pieces of data that hash to the same value, and the chances of it happening by accident are almost 0. MD5 has been found to have some weaknesses, such that with some complex mathematics, it may be possible to find a collision without trying out 2128 possible input strings. And the fact that most passwords are short, and people often use common values (like "password" or "secret") means that in some cases, you can make a reasonably good guess at someone's password by Googling for the hash or using a Rainbow table. That is one reason why you should always "salt" hashed passwords, so that two identical values, when hashed, will not hash to the same value. Once a piece of data has been run through a hash function, there is no going back.

I have seen this done for video game releases. Customers are allowed to download an encrypted copy of the game in advance. Then, when the release time comes, the game company simply releases the key. That way, people can start playing immediately when the game is released, without needing to wait for a download.

Or (all answers are valid):

1. You may be interested in time-lock puzzles. The idea is to be able to make a problem instance that is easy to build but expensive to open, where the cost is configurable. Of course this does not guarantee a release at a specific date; rather, it guarantees a minimum effort to unlock the puzzle. Conversion between effort and date depends on how hard attackers try. In other words, if an attacker wants to get your file earlier, he just has to buy a faster computer.
2. Time is relative, but the speed of light is absolute. Put the decryption key sufficient distance away from the attackers. No powerful computer can overcome that. For example, you can use a mirror at some x/2 light years away, and then transmit the key to that mirror. Assuming no-one is able to sniff/disturb it, you'd have the appropriate delay of x years.
3. Carefully place a spaceship broadcasting the decryption key in orbit around a black hole. The pull of gravity will delay the message until the appropriate time.

The short answer is that JWT doesn't concern itself with encryption. It cares about validation. That is to say, it can always get the answer for "Have the contents of this token manipulated"? This means user manipulation of the JWT token is futile because the server will know and disregard the token. JWT isn't meant to store sensitive data. Once the server receives the JWT token and validates it, it is free to lookup the user ID in its own database for additional information for that user (like permissions, postal address, etc). This keeps JWT small in size and avoids inadvertent information leakage because everyone knows not to keep sensitive data in JWT.

OpenID is (mainly) for identification/authentication, so that stackoverflow.com knows that I own chris.boyle.name (or wherever) and therefore that I am probably the same person who owned chris.boyle.name yesterday and earned some reputation points. OAuth is designed for authorization to take actions on your behalf, so that stackoverflow.com (or wherever) can ask permission to, say, Tweet on your behalf automatically, without knowing your Twitter password.

CORS (Cross-origin resource sharing) is a technique that allows restricted resources on a web page to be

requested from another domain outside the domain of which the first resource was served. A web page may freely attach cross-origin images, scripts, stylesheets, iframes, and videos. The same-origin security policy by default does not allow certain “cross-domain” requests, notably Ajax requests. Cross-origin resource sharing provides a way by which a browser and server can interact to determine whether allowing the cross-origin requests are safe or not.

SSL (and its successor, TLS) is a protocol that operates directly on top of TCP. This way, protocols on higher

layers (such as HTTP) can be left unchanged while still providing a secure connection. Underneath the SSL layer,

HTTP is identical to HTTPS. When using SSL/TLS correctly, all an attacker can see on the cable is which IP and port you are connected to, roughly how much data you are sending, and what encryption and compression is used. He can also terminate the connection, but both sides will know that the connection has been interrupted by a third party.

1. After building a TCP connection, the SSL handshake is started by the client that sends a number of specifications:

which version of SSL/TLS it is running, what ciphersuites it wants to use, and what compression methods it wants to use. 2. The server checks what the highest SSL/TLS version is that is supported by them both, picks a ciphersuite from one of the client's options (if it supports one), and optionally picks a compression method. 3. After this the basic setup is done, the server sends its certificate. This certificate must be trusted by either the client itself or a party that the client trusts. Having verified the certificate and being certain this server really is who he claims to be (and not a man in the middle), a key is exchanged. The client tells the server that from now on, all communication will be encrypted, and sends an encrypted and authenticated message to the server. 4. The server verifies that the MAC (used for authentication) is correct, and that the message can be correctly decrypted. It then returns a message, which the client verifies as well. 5. The handshake is now finished, and the two hosts can communicate securely.

By using XST technique, attackers are able to steal cookies by bypassing “http only” attribute. XST technique can be prevented by disabling TRACE method on the web server.

Reflected XSS is one of the most widespread attack technique used by attackers. In this type of attack, the user sends a malicious request by clicking on malicious links (contains an XSS payload) to web server available on social networking sites and other platforms. As a result, web server replied back to the user with HTTP response which contains the payload which in turns executed in the browser and steal cookies of the user.

In Stored XSS, attacker plants a malicious script (also called payload) on a web page. Comment page, forums, and other similar platforms can be used to store payloads. When the user browses these pages, these payloads executed and sends cookies information to an attacker.

This can be mitigated by using secure techniques for proper authentication and proper authorization for each page of the web application. Some mitigation techniques are described below: Implement Authentication and authorization policies based on role, instead of based on the user. Policies are highly configurable in favor of standard practices. Deny all access by default, and allow only those controls which are needed by the user.

Bug bounty is a program run by many big organizations which reward those individuals who report security vulnerabilities to them. These organizations generally publish those vulnerabilities on websites after fixing those issues.

Run: curl -s -D- https://example.com/ | grep -i Strict-Transport-Security Hence, if HSTS is enabled, there will be an STS header with the “max-age” directive value. In an opposite case, there would be no message from the server, since there is nothing to send in response to the above stated command.

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. The HSTS Policy is communicated by the server to the user agent via an HTTPS response header field namedStrict-Transport-Security. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.

The input material can be an infinite length, where the output is always 128 bits long (for MD5 hash). This means that an infinite number of input strings will generate the same output. If you pick a random number and divide it by 2 but only write down the remainder, you'll get either a 0 or 1 - even or odd, respectively. Is it possible to take that 0 or 1 and get the original number?

Use the X-Frame-Options HTTP header is one of the options to prevent clickjacking. It allows an application to specify whether frame use is simply denied, via the DENY value, or the use of frames is allowed, by the SAMEORIGIN or ALLOW-FROM values. Mainstream modern browsers do support this header option, but other browsers may not. Possible X-Frame-Options: X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM https://example.com/