Comparaciones entre SSRF, CSRF, XSS y XFS

Este es el primero de una serie de artículos relacionados con la seguridad. 

• Los 10 principales riesgos de seguridad de las aplicaciones web  
• Inyección SQL 
• Falsificación de solicitud del lado del servidor (SSRF)
  • Ejemplo de falsificación de solicitud del lado del servidor
• Falsificación de solicitud entre sitios (CSRF)
• Secuencias de comandos entre sitios (XSS)
  • Ejemplo de Cross-Site Scripting, reflejado
  • Ejemplo de Cross-Site Scripting, DOM
• Secuencias de comandos entre fotogramas (XFS)
  • Ejemplo de secuencias de comandos entre fotogramas
• Comparaciones entre SSRF, CSRF, XSS y XFS  ---  este artículo
• CORS (1), consumir .NET Core Web API por MVC en el mismo origen

Esta es una parte resumida de esta serie de artículos con una comparación entre SSRF, CSRF, XSS y XFS.

A - ¿Qué es SSRF, CSRF, XSS, XFS?

Ignoraremos la definición de adjuntar para vulnerabilidades, uno puede verificar las definiciones en los artículos relacionados, solo nos enfocamos en las diferencias de los mecanismos de adjuntar. 

A-1: SSRF

Los puntos son que el atacante puede

• Acceder al Servidor;
• Abusar de la funcionalidad en el servidor.

A-2: CSRF

Los puntos son que el atacante puede

• Acceder al Servidor;
• Cambie los estados en el servidor.

A-3: XS

Los puntos son que el atacante puede

• Acceda al navegador web del cliente;
• Ejecute el código malicioso en el navegador.
• Acceda y controle la funcionalidad y los datos de la aplicación

A-4: XFS

Los puntos son que el atacante puede

• Deje que la víctima sea engañada para acceder a una página web maliciosa a través de su navegador;
• Cargue una página de terceros en el marco HTML.
• Robar los datos de la víctima grabando las pulsaciones de teclas de la víctima

resumido como

	Objetivo de ataque	Tipo de ataque
SSRF	Servidor	Funcionalidad de abuso
CSRF	Servidor	Cambian de estado
XSS	Navegador	Controle la funcionalidad y los datos de la aplicación
XFS	iFrame del navegador	Robar datos grabando pulsaciones de teclas

B - ¿Cómo funciona SSRF, CSRF, XSS o XFS?
 

B-1: Explotación típica de una vulnerabilidad SSRF a través de un servidor web

Debido a la protección del firewall del sistema, un atacante externo no puede usar solicitudes directas, sino que realiza su ataque a través de un  servidor web vulnerable .

En un ataque SSRF típico, el atacante puede hacer que el servidor establezca una conexión con servicios solo internos dentro de la infraestructura de la organización. En otros casos, pueden obligar al servidor a conectarse a sistemas externos arbitrarios, lo que podría filtrar datos confidenciales, como credenciales de autorización.

B-2: Explotación típica de una vulnerabilidad CSRF a través de un servidor web

La falsificación de solicitudes entre sitios (también conocida como CSRF) permite a un atacante inducir a los usuarios a realizar acciones que no tienen la intención de realizar. Permite que un atacante eluda parcialmente la misma política de origen, que está diseñada para evitar que diferentes sitios web interfieran entre sí.

B-3: Explotación típica de una vulnerabilidad XSS a través de un navegador web

Las secuencias de comandos entre sitios funcionan mediante la manipulación de un sitio web vulnerable para que devuelva JavaScript malicioso a los usuarios. Cuando el código malicioso se ejecuta dentro del navegador de la víctima, el atacante puede comprometer completamente su interacción con la aplicación.

B-4: Explotación típica de una vulnerabilidad XFS a través de un navegador de usuario con iFrame

Un ataque de secuencias de comandos entre marcos comienza al incorporar una página web válida en un  iframe  en una página maliciosa y engañar al usuario para que visite un sitio que controla el atacante, generalmente como parte de un ataque de phishing. JavaScript está configurado en el servidor del atacante para escuchar eventos iniciados por el usuario, generalmente pulsaciones de teclas, y el atacante puede expandir el iframe para cubrir toda la página para obtener el máximo realismo.

En combinación con un error de navegador adecuado, esto puede permitir que el atacante obtenga credenciales de inicio de sesión y otra información confidencial del usuario desprevenido que interactúa con el sitio legítimo enmarcado como de costumbre. Desde este punto de vista, XFS puede considerarse una variedad de  clickjacking .

 

C - Manera Típica de Introducir una Vulnerabilidad

 

C-1: SSRF

Se introduce una vulnerabilidad SSRF cuando  se utilizan datos controlables por el usuario  para crear la URL de destino. Para realizar un ataque SSRF, un atacante puede cambiar el valor de un parámetro en la aplicación web vulnerable para crear o controlar solicitudes desde el servidor vulnerable.

Los recursos externos a los que accede una aplicación web pueden incluir servicios internos, por ejemplo, una fuente RSS de otro sitio web. Un desarrollador podría usar la siguiente URL para recuperar una fuente remota:

https://example.com/feed.php?url=externalsite.com/feed/to

HTTP

Dupdo

Si el atacante puede cambiar el  url parámetro a  localhost (la interfaz de bucle invertido), esto puede permitirle ver los recursos locales alojados en el servidor, haciéndolo vulnerable a la falsificación de solicitudes del lado del servidor.

C-2: CSRF

Para que un ataque CSRF sea posible, deben darse tres condiciones clave:

• Una acción relevante.  Hay una acción dentro de la aplicación que el atacante tiene una razón para inducir. Esto podría ser una acción privilegiada (como modificar los permisos de otros usuarios) o cualquier acción sobre datos específicos del usuario (como cambiar la contraseña del usuario).
• Manejo de sesión basado en cookies.  Realizar la acción implica emitir una o más solicitudes HTTP, y la aplicación se basa únicamente en las cookies de sesión para identificar al usuario que realizó las solicitudes. No existe ningún otro mecanismo para realizar un seguimiento de las sesiones o validar las solicitudes de los usuarios.
• Sin parámetros de solicitud impredecibles.  Las solicitudes que realizan la acción no contienen ningún parámetro cuyos valores el atacante no pueda determinar o adivinar. Por ejemplo, al hacer que un usuario cambie su contraseña, la función no es vulnerable si un atacante necesita saber el valor de la contraseña.

C-3: XS

Los ataques XSS son ataques  de inyección  que insertan código de script malicioso en una página web procesada por el navegador de un usuario. La parte “ cross-site ” significa que el código de ataque tiene un origen diferente al del sitio visitado. Normalmente, esto debería ser imposible debido a  la política del mismo origen (SOP)  , una función de seguridad fundamental del navegador que solo permite que las aplicaciones web carguen scripts que tienen el mismo origen.

C-4: XFS

En un ataque XFS típico, una vez que el usuario del navegador visita la página web controlada por el atacante, ocurre lo siguiente:

1. La página legítima (generalmente una página de inicio de sesión) se abre en un elemento HTML IFRAME.
2. El elemento IFRAME se maximiza para llenar toda la página y los bordes del marco se eliminan para que el usuario desprevenido piense que está visitando el sitio legítimo.
3. Cuando la víctima intenta iniciar sesión en el sitio web o la aplicación web legítimos, el JavaScript malicioso fuera del IFRAME captura los eventos del teclado (pulsaciones de teclas) y se los envía al atacante.

Fuente: https://www.c-sharpcorner.com/article/comparisons-among-ssrf-csrf-xss-and-xfs/ 

#ssrf #csrf #xss #xfs 

What is GEEK

Buddha Community

Comparaciones entre SSRF, CSRF, XSS y XFS

Este es el primero de una serie de artículos relacionados con la seguridad. 

• Los 10 principales riesgos de seguridad de las aplicaciones web  
• Inyección SQL 
• Falsificación de solicitud del lado del servidor (SSRF)
  • Ejemplo de falsificación de solicitud del lado del servidor
• Falsificación de solicitud entre sitios (CSRF)
• Secuencias de comandos entre sitios (XSS)
  • Ejemplo de Cross-Site Scripting, reflejado
  • Ejemplo de Cross-Site Scripting, DOM
• Secuencias de comandos entre fotogramas (XFS)
  • Ejemplo de secuencias de comandos entre fotogramas
• Comparaciones entre SSRF, CSRF, XSS y XFS  ---  este artículo
• CORS (1), consumir .NET Core Web API por MVC en el mismo origen

Esta es una parte resumida de esta serie de artículos con una comparación entre SSRF, CSRF, XSS y XFS.

A - ¿Qué es SSRF, CSRF, XSS, XFS?

Ignoraremos la definición de adjuntar para vulnerabilidades, uno puede verificar las definiciones en los artículos relacionados, solo nos enfocamos en las diferencias de los mecanismos de adjuntar. 

A-1: SSRF

Los puntos son que el atacante puede

• Acceder al Servidor;
• Abusar de la funcionalidad en el servidor.

A-2: CSRF

Los puntos son que el atacante puede

• Acceder al Servidor;
• Cambie los estados en el servidor.

A-3: XS

Los puntos son que el atacante puede

• Acceda al navegador web del cliente;
• Ejecute el código malicioso en el navegador.
• Acceda y controle la funcionalidad y los datos de la aplicación

A-4: XFS

Los puntos son que el atacante puede

• Deje que la víctima sea engañada para acceder a una página web maliciosa a través de su navegador;
• Cargue una página de terceros en el marco HTML.
• Robar los datos de la víctima grabando las pulsaciones de teclas de la víctima

resumido como

	Objetivo de ataque	Tipo de ataque
SSRF	Servidor	Funcionalidad de abuso
CSRF	Servidor	Cambian de estado
XSS	Navegador	Controle la funcionalidad y los datos de la aplicación
XFS	iFrame del navegador	Robar datos grabando pulsaciones de teclas

B - ¿Cómo funciona SSRF, CSRF, XSS o XFS?
 

B-1: Explotación típica de una vulnerabilidad SSRF a través de un servidor web

Debido a la protección del firewall del sistema, un atacante externo no puede usar solicitudes directas, sino que realiza su ataque a través de un  servidor web vulnerable .

En un ataque SSRF típico, el atacante puede hacer que el servidor establezca una conexión con servicios solo internos dentro de la infraestructura de la organización. En otros casos, pueden obligar al servidor a conectarse a sistemas externos arbitrarios, lo que podría filtrar datos confidenciales, como credenciales de autorización.

B-2: Explotación típica de una vulnerabilidad CSRF a través de un servidor web

La falsificación de solicitudes entre sitios (también conocida como CSRF) permite a un atacante inducir a los usuarios a realizar acciones que no tienen la intención de realizar. Permite que un atacante eluda parcialmente la misma política de origen, que está diseñada para evitar que diferentes sitios web interfieran entre sí.

B-3: Explotación típica de una vulnerabilidad XSS a través de un navegador web

Las secuencias de comandos entre sitios funcionan mediante la manipulación de un sitio web vulnerable para que devuelva JavaScript malicioso a los usuarios. Cuando el código malicioso se ejecuta dentro del navegador de la víctima, el atacante puede comprometer completamente su interacción con la aplicación.

B-4: Explotación típica de una vulnerabilidad XFS a través de un navegador de usuario con iFrame

Un ataque de secuencias de comandos entre marcos comienza al incorporar una página web válida en un  iframe  en una página maliciosa y engañar al usuario para que visite un sitio que controla el atacante, generalmente como parte de un ataque de phishing. JavaScript está configurado en el servidor del atacante para escuchar eventos iniciados por el usuario, generalmente pulsaciones de teclas, y el atacante puede expandir el iframe para cubrir toda la página para obtener el máximo realismo.

En combinación con un error de navegador adecuado, esto puede permitir que el atacante obtenga credenciales de inicio de sesión y otra información confidencial del usuario desprevenido que interactúa con el sitio legítimo enmarcado como de costumbre. Desde este punto de vista, XFS puede considerarse una variedad de  clickjacking .

 

C - Manera Típica de Introducir una Vulnerabilidad

 

C-1: SSRF

Se introduce una vulnerabilidad SSRF cuando  se utilizan datos controlables por el usuario  para crear la URL de destino. Para realizar un ataque SSRF, un atacante puede cambiar el valor de un parámetro en la aplicación web vulnerable para crear o controlar solicitudes desde el servidor vulnerable.

Los recursos externos a los que accede una aplicación web pueden incluir servicios internos, por ejemplo, una fuente RSS de otro sitio web. Un desarrollador podría usar la siguiente URL para recuperar una fuente remota:

https://example.com/feed.php?url=externalsite.com/feed/to

HTTP

Dupdo

Si el atacante puede cambiar el  url parámetro a  localhost (la interfaz de bucle invertido), esto puede permitirle ver los recursos locales alojados en el servidor, haciéndolo vulnerable a la falsificación de solicitudes del lado del servidor.

C-2: CSRF

Para que un ataque CSRF sea posible, deben darse tres condiciones clave:

• Una acción relevante.  Hay una acción dentro de la aplicación que el atacante tiene una razón para inducir. Esto podría ser una acción privilegiada (como modificar los permisos de otros usuarios) o cualquier acción sobre datos específicos del usuario (como cambiar la contraseña del usuario).
• Manejo de sesión basado en cookies.  Realizar la acción implica emitir una o más solicitudes HTTP, y la aplicación se basa únicamente en las cookies de sesión para identificar al usuario que realizó las solicitudes. No existe ningún otro mecanismo para realizar un seguimiento de las sesiones o validar las solicitudes de los usuarios.
• Sin parámetros de solicitud impredecibles.  Las solicitudes que realizan la acción no contienen ningún parámetro cuyos valores el atacante no pueda determinar o adivinar. Por ejemplo, al hacer que un usuario cambie su contraseña, la función no es vulnerable si un atacante necesita saber el valor de la contraseña.

C-3: XS

Los ataques XSS son ataques  de inyección  que insertan código de script malicioso en una página web procesada por el navegador de un usuario. La parte “ cross-site ” significa que el código de ataque tiene un origen diferente al del sitio visitado. Normalmente, esto debería ser imposible debido a  la política del mismo origen (SOP)  , una función de seguridad fundamental del navegador que solo permite que las aplicaciones web carguen scripts que tienen el mismo origen.

C-4: XFS

En un ataque XFS típico, una vez que el usuario del navegador visita la página web controlada por el atacante, ocurre lo siguiente:

1. La página legítima (generalmente una página de inicio de sesión) se abre en un elemento HTML IFRAME.
2. El elemento IFRAME se maximiza para llenar toda la página y los bordes del marco se eliminan para que el usuario desprevenido piense que está visitando el sitio legítimo.
3. Cuando la víctima intenta iniciar sesión en el sitio web o la aplicación web legítimos, el JavaScript malicioso fuera del IFRAME captura los eventos del teclado (pulsaciones de teclas) y se los envía al atacante.

Fuente: https://www.c-sharpcorner.com/article/comparisons-among-ssrf-csrf-xss-and-xfs/ 

#ssrf #csrf #xss #xfs 

Comparisons Among SSRF, CSRF, XSS And XFS

This is a summary part of this series of articles with comparison among SSRF, CSRF, XSS, and XFS.

A - What is SSRF, CSRF, XSS, XFS

We will ignore the definition of the attach for vulnerabilities, one can check the definitions in the related articles, we just focus on the differences of the attaching mechanisms. 

A-1: SSRF

The points are that attacker can

• Access the Server;
• Abuse functionality on the Server.

A-2: CSRF

The points are that attacker can

• Access the Server;
• Change the States on the Server.

A-3: XSS

The points are that attacker can

• Access the Client Web Browser;
• Execute the malicious code on the Browser.
• Access and Control the App's functionality and data

A-4: XFS

The points are that attacker can

• Let the victim be tricked into accessing a malicious web page via his browser;
• Load a third-party page in the HTML frame.
• Steal the victim's data by recording the victim's keystrokes

Summarized as

	Attack Target	Attack Type
SSRF	Server	Abuse Functionality
CSRF	Server	Change State
XSS	Browser	Control App's Functionality and Data
XFS	Browser iFrame	Steal Data by Recording keystrokes

B - How does SSRF, CSRF, XSS, or XFS Works
 

B-1: Typical exploitation of a SSRF Vulnerability via a Web Server

Due to the protection of system firewall, an external attacker can’t use direct requests, instead, they make their attack via a vulnerable web server.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

B-2: Typical exploitation of a CSRF Vulnerability via a Web Server

Cross-site request forgery (also known as CSRF) allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.

B-3: Typical exploitation of a XSS Vulnerability via a Web Broswer

Cross-site scripting works by manipulating a vulnerable website so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

B-4: Typical exploitation of a XFS Vulnerability via a User Browser with iFrame

A cross-frame scripting attack starts by embedding a valid webpage into an iframe on a malicious page and tricking the user into visiting a site that the attacker controls, usually as part of a phishing attack. JavaScript is set up on the attacker’s server to listen for user-initiated events, usually keypresses, and the attacker can expand the iframe to cover the entire page for maximum realism.

In combination with a suitable browser bug, this may allow the attacker to obtain login credentials and other sensitive information from the unsuspecting user who is interacting with the framed legitimate site as usual. From this point of view, XFS can be considered a variety of clickjacking.

 

C - Typical Way to Introduce a Vulnerability

 

C-1: SSRF

An SSRF vulnerability is introduced when user-controllable data is used to build the target URL. To perform an SSRF attack, an attacker can then change a parameter value in the vulnerable web application to create or control requests from the vulnerable server.

External resources accessed by a web application may include internal services, for example an RSS feed from another website. A developer might use the following URL to retrieve a remote feed:

https://example.com/feed.php?url=externalsite.com/feed/to

HTTP

Copy

If the attacker is able to change the url parameter to localhost (the loopback interface), this may allow them to view local resources hosted on the server, making it vulnerable to server-side request forgery.

C-2: CSRF

For a CSRF attack to be possible, three key conditions must be in place:

• A relevant action. There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password).
• Cookie-based session handling. Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
• No unpredictable request parameters. The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the

C-3: XSS

XSS attacks are injection attacks that insert malicious script code into a web page processed by a user’s browser. The “cross-site” part means that the attack code has a different origin than the visited site. Normally, this should be impossible due to same-origin policy (SOP) – a fundamental browser security feature that only allows web applications to load scripts that have the same origin.

C-4: XFS

In a typical XFS attack, once the browser user visits the web page controlled by the attacker, the following happens:

1. The legitimate page (usually a login page) is opened in an HTML IFRAME element.
2. The IFRAME element is maximized to fill the entire page and the frame’s borders are removed so that the unsuspecting user thinks that they are visiting the legitimate site.
3. When the victim attempts to log in to the legitimate website or web application, malicious JavaScript outside the IFRAME captures keyboard events (keystrokes) and sends them to the attacker.

Source: https://www.c-sharpcorner.com/article/comparisons-among-ssrf-csrf-xss-and-xfs/

#ssrf #csrf #xss #xfs 

SSRF、CSRF、XSS、XFSの比較

これは、一連のセキュリティ関連の記事の最初のものです。 

• Webアプリケーションのセキュリティリスクトップ10
• SQLインジェクション   
• サーバーサイドリクエストフォージェリ（SSRF）
  • サーバー側のリクエストフォージェリの例
• クロスサイトリクエストフォージェリ（CSRF）
• クロスサイトスクリプティング（XSS）
  • クロスサイトスクリプティングの例、反映
  • クロスサイトスクリプティング、DOMの例
• クロスフレームスクリプティング（XFS）
  • クロスフレームスクリプティングの例
• SSRF、CSRF、XSS、XFSの比較 --- この記事
• CORS（1）、同じオリジンのMVCで.NET CoreWebAPIを使用する

これは、SSRF、CSRF、XSS、およびXFSを比較した、この一連の記事の要約部分です。

A-SSRF、CSRF、XSS、XFSとは何ですか

脆弱性のアタッチの定義は無視します。関連記事で定義を確認できます。アタッチメカニズムの違いに焦点を当てます。 

A-1：SSRF

ポイントは、攻撃者ができることです

• サーバーにアクセスします。
• サーバーの機能を悪用します。

A-2：CSRF

ポイントは、攻撃者ができることです

• サーバーにアクセスします。
• サーバーの状態を変更します。

A-3：XSS

ポイントは、攻撃者ができることです

• クライアントWebブラウザにアクセスします。
• ブラウザで悪意のあるコードを実行します。
• アプリの機能とデータにアクセスして制御する

A-4：XFS

ポイントは、攻撃者ができることです

• 被害者をだまして、ブラウザを介して悪意のあるWebページにアクセスさせます。
• HTMLフレームにサードパーティのページをロードします。
• 被害者のキーストロークを記録して被害者のデータを盗む

として要約

	攻撃対象	攻撃タイプ
SSRF	サーバ	不正使用機能
CSRF	サーバ	状態の変更
XSS	ブラウザ	アプリの機能とデータを制御する
XFS	ブラウザiFrame	キーストロークを記録してデータを盗む

B-SSRF、CSRF、XSS、またはXFSはどのように機能しますか
 

B-1：Webサーバーを介したSSRFの脆弱性の一般的な悪用

システムファイアウォールの保護により、外部の攻撃者は直接リクエストを使用できません。代わりに、 脆弱なWebサーバーを介して攻撃を行います。

一般的なSSRF攻撃では、攻撃者がサーバーに組織のインフラストラクチャ内の内部専用サービスへの接続を確立させる可能性があります。また、サーバーを強制的に任意の外部システムに接続させて、認証資格情報などの機密データを漏洩させる可能性がある場合もあります。

B-2：Webサーバーを介したCSRF脆弱性の一般的な悪用

クロスサイトリクエストフォージェリ（CSRFとも呼ばれます）を使用すると、攻撃者はユーザーに意図しないアクションを実行させることができます。これにより、攻撃者は、異なるWebサイトが相互に干渉するのを防ぐように設計された同一生成元ポリシーを部分的に回避できます。

B-3：Webブラウザを介したXSS脆弱性の一般的な悪用

クロスサイトスクリプティングは、脆弱なWebサイトを操作して、悪意のあるJavaScriptをユーザーに返すことで機能します。悪意のあるコードが被害者のブラウザ内で実行されると、攻撃者はアプリケーションとのやり取りを完全に侵害する可能性があります。

B-4：iFrameを使用したユーザーブラウザを介したXFSの脆弱性の一般的な悪用

クロスフレームスクリプティング攻撃は、悪意のあるページのiframe に有効なWebページを埋め込み 、通常はフィッシング攻撃の一部として、攻撃者が制御するサイトにユーザーを騙してアクセスさせることから始まります。JavaScriptは、ユーザーが開始したイベント（通常はキー押下）をリッスンするように攻撃者のサーバーに設定され、攻撃者はiframeを拡張してページ全体をカバーし、最大限のリアリズムを実現できます。

これは、適切なブラウザのバグと組み合わせて、攻撃者が通常どおりフレーム化された正当なサイトと対話している疑いを持たないユーザーからログイン資格情報やその他の機密情報を取得する可能性があります。この観点から、XFSはさまざまなクリックジャッキングと見なすことができ ます。

 

C-脆弱性を導入する一般的な方法

 

C-1：SSRF

SSRFの脆弱性は、 ユーザーが制御可能なデータ を使用してターゲットURLを構築する場合に発生します。SSRF攻撃を実行するために、攻撃者は脆弱なWebアプリケーションのパラメーター値を変更して、脆弱なサーバーからの要求を作成または制御できます。

Webアプリケーションによってアクセスされる外部リソースには、別のWebサイトからのRSSフィードなどの内部サービスが含まれる場合があります。開発者は、次のURLを使用してリモートフィードを取得する場合があります。

https://example.com/feed.php?url=externalsite.com/feed/to

HTTP

コピー

攻撃者が url パラメータを localhost （ループバックインターフェイス）に変更できる場合、サーバーでホストされているローカルリソースを表示できる可能性があり、サーバー側のリクエストフォージェリに対して脆弱になります。

C-2：CSRF

CSRF攻撃を可能にするには、次の3つの重要な条件が整っている必要があります。

• 関連するアクション。 攻撃者が誘発する理由があるアプリケーション内のアクションがあります。これは、特権アクション（他のユーザーのアクセス許可の変更など）またはユーザー固有のデータに対するアクション（ユーザー自身のパスワードの変更など）である可能性があります。
• Cookieベースのセッション処理。 アクションの実行には、1つ以上のHTTP要求の発行が含まれ、アプリケーションは、要求を行ったユーザーを識別するためにセッションCookieのみに依存します。セッションを追跡したり、ユーザー要求を検証したりするためのメカニズムは他にありません。
• 予測できないリクエストパラメータはありません。 アクションを実行するリクエストには、攻撃者が決定または推測できない値のパラメータは含まれていません。たとえば、ユーザーにパスワードを変更させる場合、攻撃者がパスワードの値を知る必要がある場合、関数は脆弱ではありません。

C-3：XSS

XSS攻撃は  、ユーザーのブラウザによって処理されるWebページに悪意のあるスクリプトコードを挿入するインジェクション攻撃です。「クロスサイト」の部分は、攻撃コードが訪問したサイトとは異なる発信元を持っていることを意味します。通常、これは同一生成元ポリシー（SOP）のために不可能です。これは  、Webアプリケーションが同じ生成元を持つスクリプトのみをロードできるようにする基本的なブラウザーセキュリティ機能です。

C-4：XFS

一般的なXFS攻撃では、ブラウザユーザーが攻撃者によって制御されているWebページにアクセスすると、次のようになります。

1. 正当なページ（通常はログインページ）は、HTMLIFRAME要素で開かれます。
2. IFRAME要素はページ全体を埋めるように最大化され、フレームの境界線が削除されるため、疑いを持たないユーザーは、正当なサイトにアクセスしていると思います。
3. 被害者が正規のWebサイトまたはWebアプリケーションにログインしようとすると、IFRAMEの外部にある悪意のあるJavaScriptがキーボードイベント（キーストローク）をキャプチャし、攻撃者に送信します。

ソース：https ：//www.c-sharpcorner.com/article/comparisons-among-ssrf-csrf-xss-and-xfs/

#ssrf #csrf #xss #xfs 

Entre Institute Review - Scam or Trusty? $10k/Mo BIZ Model?

Entre Institute is an Entrepreneurship Educational Platform that currently teaching 150,000 people around the world to build their online business successfully. Jeff Lerner is the mastermind behind The Entre Institute. After a decade of building multiple online businesses to over 8 figures and twice landing on the INC 5000, Jeff turned his focus to educating and inspiring entrepreneurs about the power of entrepreneurship in the modern economy. In 2018 he founded ENTRE Institute where over 50,000 students are developing their ENTREpreneurial skills.

More Details: Entre Institute Review

#entre institute review #entre institute #entre #entre blueprint #entrepreneurship

Problema De Protección CSRF Y Cómo Solucionarlo

Un día estaba trabajando en una función en el trabajo. Tenía muchas sucursales creadas en los tickets de JIRA, así que quería abrir un montón de PR (Solicitudes de extracción) todas a la vez en diferentes pestañas.

Así es como suelo trabajar: tengo muchas pestañas abiertas y esto acelera las cosas, porque no necesito esperar a que se cargue la siguiente página.

Pero después de crear el primer PR en BitBucket e intentar pasar a la página siguiente, recibí un mensaje de error sobre un token CSRF no válido. Este es un problema común con las aplicaciones web que tienen protección CSRF.

Entonces, en este artículo, aprenderá qué es CSRF y cómo solucionar este error.

¿Qué es CSRF?

CSRF es un acrónimo de Cross-Site Request Forgery . Es un vector de ataque que los atacantes suelen utilizar para acceder a su sistema.

La forma en que generalmente se protege contra CSRF es enviar un token único generado por cada solicitud HTTP. Si el token que está en el servidor no coincide con el de la solicitud, le muestra un error al usuario.

Protección CSRF estándar

Esta es una forma de protegerse contra CSRF con un token:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER]
        });
        return response;
    };
})(inital_token);

Este código usa la API de obtención para enviar y recibir un token seguro en los encabezados HTTP . En el respaldo, debe generar el primer token inicial cuando se carga la página. En el servidor, en cada solicitud de AJAX , debe verificar si el token es válido.

El problema con las fichas

Esto funciona bien a menos que tenga más de una pestaña abierta. Cada pestaña puede enviar solicitudes al servidor, lo que romperá esta solución. Y es posible que los usuarios avanzados no puedan usar su aplicación de la manera que quieren.

Pero hay una solución simple a este problema que es la comunicación cruzada.

Solución de comunicación de tabulación cruzada

biblioteca Sysend

Puede usar la biblioteca Sysend , una solución de código abierto que he creado específicamente para este propósito. Simplifica la comunicación entre tabulaciones cruzadas.

Si lo desea, puede usar una API de navegador nativa como Broadcast Channel para hacer lo mismo. Más información sobre cómo hacerlo más adelante en este artículo.

Pero la biblioteca Sysend funcionará para navegadores que no admitan Broadcast Channel. También funciona en IE (tiene algunos errores, lo cual no es una sorpresa). Es posible que también deba admitir algunos navegadores móviles antiguos. También tiene una API mucho más simple.

Este es el ejemplo más simple:

let token;
sysend.on('token', new_token => {
    token = new_token;
});

// ...

sysend.broadcast('token', token);

Ejemplo simple de usar la función base de la biblioteca sysend

Y así es como usaría esta biblioteca para arreglar la protección CSRF:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const EVENT_NAME = 'csrf';
    sysend.on(EVENT_NAME, new_token => {
        // get new toke from different tab
        token = new_token;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new toke to other tabs
           sysend.broadcast(EVENT_NAME, token); 
        });
        return response;
    };
})(inital_token);

función secure_fetch con protección CSRF usando sysend

Todo lo que tienes que hacer es enviar y recibir un solo mensaje de otras pestañas al enviar la solicitud. Y su aplicación protegida CSRF funcionará en muchas pestañas.

Y eso es. Esto permitirá que los usuarios avanzados usen su aplicación que tiene protección CSRF cuando quieran abrir muchas pestañas.

Canal de difusión

Este es el ejemplo más simple posible del uso de Broadcast Channel:

const channel = new BroadcastChannel('my-connection');
channel.addEventListener('message', (e) => {
    console.log(e.data); // 'some message'
});
channel.postMessage('some message');

Uso básico del canal de transmisión

Entonces, con esta API simple, puede hacer lo mismo que hicimos antes:

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const channel = new BroadcastChannel('csrf-protection');
    channel.addEventListener('message', (e) => {
        // get new toke from different tab
    	token = e.data;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new token to other tabs
           channel.postMessage(token);
        });
        return response;
    };
})(inital_token);

Función secure_fetch con protección CSRF usando BroadcastChannel

Como puede ver en el ejemplo anterior, Broadcast Channel no tiene ningún espacio de nombres para eventos. Entonces, si desea enviar más de un tipo de evento, debe crear tipos de eventos.

Aquí hay un ejemplo del uso de Broadcast Channel para hacer más que la solución de protección CSRF que hemos discutido hasta ahora.

Puede sincronizar el inicio y cierre de sesión para su aplicación. Si inicia sesión en una pestaña, sus otras pestañas también lo iniciarán. De la misma manera, puede sincronizar el carrito de compras en algunos sitios web de comercio electrónico.

const channel = new BroadcastChannel('my-connection');
const CSRF = 'app/csrf';
const LOGIN = 'app/login';
const LOGOUT = 'app/logout';
let token;
channel.addEventListener('message', (e) => {
    switch (e.data.type) {
        case CSRF:
            token = e.data.payload;
            break;
        case LOGIN:
            const { user } = e.data.payload;
            autologin(user);
            break;
        case LOGOUT:
            logout();
            break;
    }
});

channel.postMessage({type: 'login', payload: { user } });

Uso de Broadcast Channel con diferentes tipos de mensajes

Conclusión

Es genial si protege su aplicación contra los atacantes. Pero tenga en cuenta cómo la gente usará su aplicación también para que no la haga innecesariamente difícil de usar. Esto se aplica no sólo a este problema en particular.

Fuente: https://www.freecodecamp.org/news/csrf-protection-problem-and-how-to-fix-it/

#csrf