How does oAuth 2.0 works?
Analogia con hotel: hotel access card would be the access token, the receptionist would be the Auth server, and the room to access would be the resource you want to access in the web app server.
Ver data flow en imagen de https://www.loginradius.com/blog/engineering/authorization-code-flow-oauth/
Explain CSRF. Give an example.
Cross-Site Request Forgery.
CSRF attacks exploit the trust a Web application has in an authenticated user. Being able to make a request as an authenticated user takes advantage of the browser’s cookies.
EXAMPLE
Let’s say that the online banking application is built using the GET method to submit a transfer request. As such, Bob’s request to transfer $500 to Alice (with account number 213367) might look like this:
GET https://samplebank.com/onlinebanking/transfer?amount=500&accountNumber=213367 HTTP/1.1
Aligning with the first requirement to successfully launch a CSRF attack, an attacker must craft a malicious URL to transfer $5,000 to their account “425654”:
https://samplebank.com/onlinebanking/transfer?amount=5000&accountNumber=425654
Using various social engineering attack methods, an attacker can trick Bob into loading the malicious URL. This can be achieved in various ways. For instance, including malicious HTML image elements onto forms, placing a malicious URL on pages that are often accessed by users while logged into the application, or by sending a malicious URL through email.
The following is an example of a disguised URL:
<img></img>
Consider the scenario that includes an image tag in an attacker-crafted email to Bob. Upon receiving it, Bob’s browser application opens this URL automatically—without human intervention. As a result, without Bob’s permission, a malicious request is sent to the online banking application. If Bob has an active session with samplebank.com, the application would treat this as an authorized amount transfer request coming from Bob. It would then transfer the amount to the account specified by an attacker.
Links to read
https://www.stackhawk.com/blog/react-csrf-protection-guide-examples-and-how-to-enable-it/
What is XSS attack? How React prevent it?
A XSS Attack is an injection of malicious JS in a website. React prevents this because, by default, React DOM escapes any values embedded in JSX before rendering them.
https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks
Be careful with dangerouslySetInnerHtml https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
How to avoid XSS attack / injections in React?
- Validate all data that flows into your application from the server or a third-party API. This cushions your application against an XSS attack, and at times, you may be able to prevent it, as well.
- Don’t mutate DOM directly. If you need to render different content, use innerText instead of innerHTML. Be extremely cautious when using escape hatches like findDOMNode or createRef in React.
- Always try to render data through JSX and let React handle the security concerns for you.
- Use dangerouslySetInnerHTML in only specific use cases. When using it, make sure you’re sanitizing all your data before rendering it on the DOM.
- Avoid writing your own sanitization techniques. It’s a separate subject on its own that requires some expertise. Use good libraries for sanitizing your data. There are a number of them, but you must compare the pros and cons of each specific to your use case before going forward with one.
Explain the “man in the middle” attack`
The hacker simulates the login of a website to get the data of the login of a user
What is HTTPS?
HTTPS is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS)
What is CSP?
Content Security Policy
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.
In addition to restricting the domains from which content can be loaded, the server can specify which protocols are allowed to be used; for example (and ideally, from a security standpoint), a server can specify that all content must be loaded using HTTPS.
WHAT ARE OWASP SECURITY RISKS?
The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
Explain SameSite COOKIE CONFIGURATION
La introducción del atributo SameSite (como se definió en la extensión RFC6265bis ), le permite declarar si su cookie debe restringirse a un contexto propio o del mismo sitio.
Setting Cookie properties SameSite=lax or SameSite=strict prevents CSRF attacks nowadays.
- Con strinct => la cookie see envia solo si el HOST, el dominion del server, es el mismo que el de la web q hace la peticion.
la cookie solo se enviará si el sitio de la cookie coincide con el sitio que se muestra actualmente en la barra URL del navegador.
Cuando el usuario esté en su sitio, la cookie se enviará con la solicitud tal y como se esperaba. Sin embargo, al seguir un enlace a su sitio, digamos desde otro sitio o mediante el correo electrónico de un amigo, en esa solicitud inicial no se enviará la cookie. Esto es bueno cuando tiene cookies relacionadas con la funcionalidad, las cuales siempre estarán detrás de una navegación inicial, como cambiar una contraseña o realizar una compra - Con Lax => la cookie see envia en request de navegacion al mismo sitio que el request, pero no en get, este es el default en Chrome.
EJEMPLO:
``<p>Look at this amazing cat!</p>
<img></img>
<p>Read the <a>article</a>.</p>
Y la cookie se configuró de la siguiente manera:
Set-Cookie: promo_shown=1; SameSite=Lax``
Cuando el lector esté en el blog de la otra persona, no se enviará la cookie cuando el navegador solicite amazing-cat.png. Sin embargo, cuando el lector siga el vínculo a cat.html en tu blog, esa solicitud incluirá la cookie. Por lo tanto, Lax es una buena opción para las cookies que afectan la visualización del sitio, y Strict es útil para las cookies relacionadas con las acciones que realiza el usuario.
- Con None => la cookie see envia siempre. De modo que puede usar None para comunicar claramente que la cookie debe enviarse intencionalmente en un contexto de terceros. Las cookies con SameSite=None también deben especificar a Secure, esto significa que requieren de un contexto seguro:
REJECTEDSet-Cookie: widget_session=abc123; SameSite=None
Cuando la cookie se establezca sin el atributo Secure será rechazada.
ACCEPTEDSet-Cookie: widget_session=abc123; SameSite=None; Secure
Debe asegurarse de conjuntar a SameSite=None con el atributo Secure.
Origin vs Host vs Referer
The ORIGIN header is the domain the request originates from.
The HOST is the domain the request is being sent to. => This header was introduced so hosting sites could include multiple domains on a single IP.
REFERER is like Origin but has more information
In order to preserve privacy, any browser request can decide to omit the Referer header. So it is probably best to only check the Origin header. (In case you want to allow for users to preserve their privacy)
