Saul Alaniz

Saul Alaniz

1649523600

Comparaciones entre SSRF, CSRF, XSS y XFS

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

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 ataqueTipo de ataque
SSRFServidorFuncionalidad de abuso
CSRFServidorCambian de estado
XSSNavegadorControle la funcionalidad y los datos de la aplicación
XFSiFrame del navegadorRobar 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 

Comparaciones entre SSRF, CSRF, XSS y XFS
坂本 篤司

坂本 篤司

1649514780

SSRF、CSRF、XSS、XFSの比較

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

これは、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 

SSRF、CSRF、XSS、XFSの比較
Saul Alaniz

Saul Alaniz

1649440080

Ejemplo De Falsificación De Solicitud Del Lado Del Servidor (SSRF)

Esta es una serie de artículos relacionados con la seguridad que escribí. Este artículo es el primero.

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

F-0: Introducción

Este artículo es parte de  la falsificación de solicitudes del lado del servidor (SSRF) , este es un ejemplo de un problema real de alta seguridad creado por un análisis estático de Fortify.

Esta es la estructura de este artículo,

  • F-0: Introducción
  • F-1: Resumen
  • F-2: Detalles
  • F-3: Ejemplo
  • F - 4: Recomendación
  • F - 5: La solución o sugerencia
  • F - 6: Falso positivo aceptado

F-1: Resumen

La función Create() en la línea 1452 inicia una conexión de red a un sistema de terceros utilizando datos controlados por el usuario para el URI del recurso. Un atacante podría aprovechar esta vulnerabilidad para enviar una solicitud en nombre del servidor de aplicaciones, ya que la solicitud se originará en la dirección IP interna del servidor de aplicaciones.

F-2: Detalles

Una falsificación de solicitud del lado del servidor ocurre cuando un atacante puede influir en una conexión de red realizada por el servidor de aplicaciones. La conexión de red se originará desde la IP interna del servidor de aplicaciones y un atacante puede usar esta conexión para eludir los controles de red y escanear o atacar recursos internos que de otro modo no estarían expuestos.

En este caso, se llama a Create() en BasePage.vb en la línea 1452.

F-3: Ejemplo

Ejemplo:  En el siguiente ejemplo, un atacante puede controlar la URL a la que se conecta el servidor.

string url = Request.Form["url"];
HttpClient client = new HttpClient();
HttpResponseMessage response = await client.GetAsync(url);

JavaScript

La capacidad del atacante para secuestrar la conexión de red depende de la parte específica del URI que se puede controlar y de las bibliotecas utilizadas para establecer la conexión. Por ejemplo, controlar el esquema URI le permite al atacante usar protocolos diferentes a HTTP o HTTPS como:

  • arriba://
  • ldap://
  • frasco://
  • ardilla de tierra://
  • enviar a: //
  • ssh2://
  • telnet://
  • esperar://

Un atacante puede aprovechar esta conexión de red secuestrada para realizar los siguientes ataques:

  • Escaneo de puertos de recursos de intranet.
  • Evitar los cortafuegos.
  • Ataca los programas vulnerables que se ejecutan en el servidor de aplicaciones o en la intranet.
  • Ataque aplicaciones web internas/externas mediante ataques de inyección o CSRF.
  • Acceda a los archivos locales usando el esquema file://.
  • En los sistemas Windows, el esquema file:// y las rutas UNC pueden permitir que un atacante escanee y acceda a recursos compartidos internos.
  • Realice un ataque de envenenamiento de caché de DNS.

F - 4: Recomendación

No establezca conexiones de red basadas en datos controlados por el usuario y asegúrese de que la solicitud se envíe al destino esperado. Si los datos del usuario son necesarios para construir el URI de destino, use un nivel de direccionamiento indirecto: cree una lista de nombres de recursos legítimos que un usuario puede especificar y solo permita que el usuario seleccione de la lista. Con este enfoque, la entrada proporcionada por el usuario nunca se usa directamente para especificar el nombre del recurso.

En algunas situaciones, este enfoque no es práctico porque el conjunto de nombres de recursos legítimos es demasiado grande o demasiado difícil de mantener. Los programadores a menudo recurren a implementar una lista de denegación en estas situaciones. Una lista de denegación se usa para rechazar o escapar selectivamente caracteres potencialmente peligrosos antes de usar la entrada. Sin embargo, es probable que cualquier lista de caracteres no seguros esté incompleta y casi con toda seguridad quedará obsoleta. Un mejor enfoque es crear una lista de caracteres que pueden aparecer en el nombre del recurso y aceptar entradas compuestas exclusivamente por caracteres del conjunto aprobado.

Además, si es necesario, asegúrese de que la entrada del usuario solo se use para especificar un recurso en el sistema de destino, pero que la aplicación controle el esquema URI, el host y el puerto. De esta manera, el daño que un atacante es capaz de hacer se reducirá significativamente.

Nota
Los F - 1 a F - 4 son principalmente del detector automático de fortificación (Micro Focus) con algunos de mis aportes (gráficos o explicaciones), F - 5 y los siguientes son aportes míos --- la solución.

F - 5: La solución o sugerencia

El problema de SSRF se crea a partir del código, Línea 1440 (ver adjunto 1): la URL es de la base de datos, que Fortify trata como "datos controlados por el usuario". El hecho es que la base de datos no es accesible para el usuario, es parte del programa con el mismo nivel de seguridad que el código, no es accesible desde fuera del firewall, por lo que no son "datos controlados por el usuario".

Por lo tanto, el problema es que Fortify trata el código como "datos controlados por el usuario", de hecho no lo es. Este es un problema de falso positivo.

F - 6: Falso positivo aceptado

Aceptar certificaciones de desarrolladores. --- Del Equipo de Seguridad de Aplicaciones.

Nota
Falso positivo aceptado significa que la herramienta (Fortify Scanner) es incorrecta:

Los falsos positivos ocurren cuando una herramienta de prueba de seguridad señala incorrectamente un problema que no es legítimo (es decir, la herramienta dice que SSL 3.0 está habilitado, pero no lo está; la herramienta estaba equivocada). En estos casos, se alienta a los equipos a seguir el proceso descrito a continuación para eliminar los problemas y asegurarnos de que se resuelva el error.

Fuente: https://www.c-sharpcorner.com/article/example-of-server-side-request-forgery/ 

#ssrf #server 

Ejemplo De Falsificación De Solicitud Del Lado Del Servidor (SSRF)
坂本 篤司

坂本 篤司

1649438820

サーバー側のリクエストフォージェリの例

これは私が書いた一連のセキュリティ関連の記事です。この記事は最初の記事です。

F-0：はじめに

この記事は サーバーサイドリクエストフォージェリ（SSRF）の一部であり、これはFortifyStaticScanningによって作成された実際の高度なセキュリティ問題の例です。

これがこの記事の構成です。

  • F-0：はじめに
  • F-1：概要
  • F-2：詳細
  • F-3：例
  • F-4：推奨事項
  • F-5：修正または提案
  • F-6：誤検知を受け入れました

F-1：概要

1452行目の関数Create（）は、リソースURIにユーザー制御データを使用して、サードパーティシステムへのネットワーク接続を開始します。リクエストはアプリケーションサーバーの内部IPアドレスから発信されるため、攻撃者はこの脆弱性を利用してアプリケーションサーバーに代わってリクエストを送信する可能性があります。

F-2：詳細

サーバー側のリクエストフォージェリは、攻撃者がアプリケーションサーバーによって確立されたネットワーク接続に影響を与える可能性がある場合に発生します。ネットワーク接続はアプリケーションサーバーの内部IPから発信され、攻撃者はこの接続を使用してネットワーク制御をバイパスし、他の方法では公開されていない内部リソースをスキャンまたは攻撃する可能性があります。

この場合、Create（）はBasePage.vbの1452行で呼び出されます。

F-3：例

例： 次の例では、攻撃者はサーバーが接続しているURLを制御できます。

string url = Request.Form["url"];
HttpClient client = new HttpClient();
HttpResponseMessage response = await client.GetAsync(url);

JavaScript

ネットワーク接続を乗っ取る攻撃者の能力は、制御できるURIの特定の部分、および接続の確立に使用されるライブラリに依存します。たとえば、URIスキームを制御すると、攻撃者は次のようなHTTPまたはHTTPSとは異なるプロトコルを使用できます。

  • 上：//
  • ldap：//
  • jar：//
  • gopher：//
  • mailto：//
  • ssh2：//
  • telnet：//
  • 予想：//

攻撃者は、この乗っ取られたネットワーク接続を利用して、次の攻撃を実行できます。

  • イントラネットリソースのポートスキャン。
  • ファイアウォールをバイパスします。
  • アプリケーションサーバーまたはイントラネットで実行されている脆弱なプログラムを攻撃します。
  • インジェクション攻撃またはCSRFを使用して、内部/外部のWebアプリケーションを攻撃します。
  • file：//スキームを使用してローカルファイルにアクセスします。
  • Windowsシステムでは、file：//スキームとUNCパスにより、攻撃者が内部共有をスキャンしてアクセスできる可能性があります。
  • DNSキャッシュポイズニング攻撃を実行します。

F-4：推奨事項

ユーザーが制御するデータに基づいてネットワーク接続を確立しないでください。また、要求が予期された宛先に送信されていることを確認してください。宛先URIを構築するためにユーザーデータが必要な場合は、間接参照のレベルを使用します。ユーザーが指定できる正当なリソース名のリストを作成し、ユーザーがリストから選択できるようにします。このアプローチでは、ユーザーが提供した入力がリソース名を指定するために直接使用されることはありません。

状況によっては、正当なリソース名のセットが大きすぎるか、維持するのが難しいため、このアプローチは実用的ではありません。プログラマーは、これらの状況で拒否リストを実装することに頼ることがよくあります。拒否リストは、入力を使用する前に、潜在的に危険な文字を選択的に拒否またはエスケープするために使用されます。ただし、そのような安全でない文字のリストは不完全である可能性が高く、ほぼ確実に古くなります。より良いアプローチは、リソース名に表示できる文字のリストを作成し、承認されたセットの文字のみで構成される入力を受け入れることです。

また、必要に応じて、ユーザー入力がターゲットシステム上のリソースを指定するためにのみ使用されることを確認しますが、URIスキーム、ホスト、およびポートはアプリケーションによって制御されます。このようにして、攻撃者が与えることができるダメージが大幅に減少します。

注
F-1からF-4は、主に強化自動検出器（Micro Focus）からのものであり、私の入力（グラフまたは説明）の一部が含まれています。F-5以下は、私自身からの入力です---ソリューション。

F-5：修正または提案

SSRFの問題は、コード1440行目（添付ファイル1を参照）から作成されます。URLはデータベースからのものであり、Fortifyによって「ユーザー制御データ」として扱われます。実際のところ、データベースはユーザーがアクセスできず、コードと同じセキュリティレベルのプログラムの一部であり、ファイアウォールの外部からアクセスできないため、「ユーザーが制御するデータ」ではありません。

したがって、Fortifyがコードを「ユーザー制御データ」として扱うという問題が発生しますが、実際にはそうではありません。これは誤検知の問題です。

F-6：誤検知を受け入れました

開発者の証明を受け入れる。---アプリケーションセキュリティチームから。

注
誤検知が受け入れられたということは、ツール（Fortify Scanner）が間違っていることを意味します。

誤検知は、セキュリティテストツールが正当ではない問題に誤ってフラグを立てた場合に発生します（つまり、ツールはSSL 3.0が有効になっていると言っていますが、そうではありません–ツールが間違っていました）。このような場合、チームは、問題を抑制し、バグを確実に解決するために、以下に概説するプロセスに従うことをお勧めします。

ソース：https ：//www.c-sharpcorner.com/article/example-of-server-side-request-forgery/

#server #ssrf 

サーバー側のリクエストフォージェリの例
Saul Alaniz

Saul Alaniz

1649429231

Falsificación De Solicitud Del Lado Del Servidor (SSRF)

Esta es una serie de artículos relacionados con la seguridad que escribí. Este artículo es el primero.

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

Introducción

En seguridad informática, la falsificación de solicitud del lado del servidor (SSRF)  es un tipo de  explotación  en la que un atacante abusa de la funcionalidad de un servidor y hace que acceda o manipule información en el ámbito de ese servidor que, de otro modo, no sería directamente accesible para el atacante. [ wiki ]

Similar a  la falsificación de solicitudes entre sitios  que utiliza un  cliente web , por ejemplo, un navegador web, dentro del dominio como proxy para ataques; un ataque SSRF utiliza un servidor inseguro dentro del dominio como  proxy .

Esta es la estructura de este artículo,

  • Introducción
  • A - ¿Qué es la falsificación de solicitudes del lado del servidor (SSRF)?
  • B - Explotación típica de una vulnerabilidad SSRF a través de un servidor web
  • C - Manera típica de introducir una vulnerabilidad SSRF
  • D - Impactos de una vulnerabilidad SSRF
  • E - Eludir las defensas comunes de la SSRF
  • F - Un ejemplo

A - ¿Qué es la falsificación de solicitudes del lado del servidor?

Me gusta esta definición:

En un ataque de falsificación de solicitud del lado del servidor (SSRF), el atacante puede acceder a un servidor y abusar de la funcionalidad en el servidor para leer o actualizar los recursos internos. 

Los puntos son que el adjunto puede

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

B - 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 escenario típico de SSRF, un atacante externo que desea acceder a un servidor interno no puede usar solicitudes directas porque el firewall las bloquearía. En cambio, los actores maliciosos pueden explotar una vulnerabilidad SSRF para realizar 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.

C - Manera típica de introducir una vulnerabilidad 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

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.

D - Impactos de una vulnerabilidad SSRF

Si los atacantes pueden controlar el destino de las solicitudes del lado del servidor, esto abre una gran variedad de actividades ofensivas, lo que potencialmente les permite:

  • Abusar de la relación de confianza entre el servidor vulnerable y otros sistemas
  • Omitir la lista blanca de IP
  • Omitir los servicios de autenticación basados ​​en host
  • Lea recursos web y otros activos útiles que no son accesibles al público, por ejemplo, API de metadatos en entornos de AWS o  trace.axd en ASP.NET
  • Realizar exploraciones de puertos en la red interna a la que está conectado el servidor
  • Leer archivos del servidor web
  • Ver páginas de estado e interactuar con las API como servidor web
  • Recupere información confidencial, como la dirección IP de un servidor web que se ejecuta detrás de un proxy inverso

E - Eludir las defensas comunes de la SSRF

Es común ver aplicaciones que contienen comportamiento SSRF junto con defensas destinadas a prevenir la explotación maliciosa. A menudo, estas defensas se pueden eludir.

E - 1: SSRF con filtros de entrada basados ​​en listas negras

Algunas aplicaciones bloquean la entrada que contiene nombres de host como  127.0.0.1 y  localhost, o direcciones URL confidenciales como  /admin. 

E - 2: SSRF con filtros de entrada basados ​​en listas blancas

Algunas aplicaciones solo permiten entradas que coincidan, comiencen o contengan una lista blanca de valores permitidos. En esta situación, a veces puede eludir el filtro aprovechando las incoherencias en el análisis de URL.

E - 3: Omisión de filtros SSRF a través de redirección abierta

A veces es posible eludir cualquier tipo de defensa basada en filtros explotando una vulnerabilidad de redirección abierta.

Fuente: https://www.c-sharpcorner.com/article/server-side-request-forgery-ssrf/

#server  #ssrf 

Falsificación De Solicitud Del Lado Del Servidor (SSRF)
坂本 篤司

坂本 篤司

1649428020

サーバーサイドリクエストフォージェリ（SSRF）とは?

これは私が書いた一連のセキュリティ関連の記事です。この記事は最初の記事です。

序章

コンピュータセキュリティでは、サーバー側リクエストフォージェリ（SSRF） は 、攻撃者がサーバーの機能を悪用 して、攻撃者が直接アクセスできないサーバーの領域内の情報にアクセスまたは操作するエクスプロイトの一種です。 [ wiki ]

ドメイン内のWebクライアント（Webブラウザなど）を攻撃のプロキシとして 利用する クロスサイトリクエストフォージェリと同様 です。SSRF攻撃は、ドメイン内の安全でないサーバーを プロキシとして利用します。

これがこの記事の構成です。

  • 序章
  • A-サーバーサイドリクエストフォージェリ（SSRF）とは
  • B-Webサーバーを介したSSRFの脆弱性の一般的な悪用
  • C-SSRFの脆弱性を導入する一般的な方法
  • D-SSRFの脆弱性の影響
  • E-一般的なSSRF防御を回避する
  • F-例

A-サーバー側のリクエストフォージェリとは何ですか

私はこの定義が好きです：

サーバーサイドリクエストフォージェリ（SSRF）攻撃では、攻撃者はサーバーにアクセスし、サーバーの機能を悪用して内部リソースを読み取ったり更新したりする可能性があります。 

ポイントは、アタッチメントができることです

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

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

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

一般的なSSRFシナリオでは、内部サーバーにアクセスしたい外部の攻撃者は、ファイアウォールによってブロックされるため、直接要求を使用できません。代わりに、悪意のある攻撃者がSSRFの脆弱性を悪用して、脆弱なWebサーバーを介して攻撃を行う可能性があります。

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

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

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

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

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

HTTP

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

D-SSRFの脆弱性の影響

攻撃者がサーバー側のリクエストの宛先を制御できる場合、これにより一連の攻撃的なアクティビティが発生し、次のことが可能になる可能性があります。

  • 脆弱なサーバーと他のシステム間の信頼関係を悪用する
  • IPホワイトリストをバイパスする
  • ホストベースの認証サービスをバイパスする
  • trace.axd AWS環境やASP.NETのメタデータAPIなど、一般にアクセスできないWebリソースやその他の有用なアセットを読み ます
  • サーバーが接続されている内部ネットワークでポートスキャンを実行します
  • Webサーバーからファイルを読み取る
  • ステータスページを表示し、WebサーバーとしてAPIを操作します
  • リバースプロキシの背後で実行されているWebサーバーのIPアドレスなどの機密情報を取得します

E-一般的なSSRF防御を回避する

SSRFの動作を含むアプリケーションと、悪意のある悪用を防ぐことを目的とした防御がよく見られます。多くの場合、これらの防御は回避できます。

E-1：ブラックリストベースの入力フィルターを使用したSSRF

127.0.0.1 一部のアプリケーションは、や などのホスト名localhost、またはなどの機密性の高いURL を含む入力をブロック します/admin。 

E-2：ホワイトリストベースの入力フィルターを使用したSSRF

一部のアプリケーションでは、許可された値のホワイトリストに一致するか、それで始まるか、またはそれを含む入力のみが許可されます。この状況では、URL解析の不整合を利用して、フィルターを回避できる場合があります。

E-3：オープンリダイレクトを介してSSRFフィルターをバイパスする

オープンリダイレクションの脆弱性を悪用することで、あらゆる種類のフィルターベースの防御を回避できる場合があります。

ソース：https ：//www.c-sharpcorner.com/article/server-side-request-forgery-ssrf/

#server  #ssrf 

サーバーサイドリクエストフォージェリ（SSRF）とは?
Ron Cartwright

Ron Cartwright

1600092000

How I hacked redbus [An online bus-ticketing application]

[I drafted this writeup 2 years ago. As it took a long time for the patch, posting it now]

It was a usual fresh and sleepy monday morning . I reached my desk and checking mails.

😴few minutes passed…

☎️ My Phone rang…

I thought thats a usual call from customer care. No. It was my mom (The only two souls who calls me daily 😅). She called me to remind about ticket booking for the weekend. That’s how it all started.

#bug-bounty #ssrf #security #vulnerability #redbus

How I hacked redbus [An online bus-ticketing application]
Hollie Ratke

Hollie Ratke

1597640400

Story of a 2.5k Bounty — SSRF on Zimbra Led to Dump All Credentials in Clear Text

This post is about how I and my friend got roughly 2500$ from Cafebazaar bug bounty program.
Init
During the recon phase, I enumerated the mailx.hezardastan.net host, the Cafebazaar’s webmail access. I conducted a port scanner:
Image for post
There were plenty of open ports. Among them, the Memcached port, 11211, was abnormal. After some basic tests, it revealed that:
There was no need to authenticate to communicate with port 11211
Email addresses were saved by Zimbra in the cache
There was the capability of adding/modifying/deleting the cache data
There was the capability of conducting a DDOS attack
However, I was looking for something more dangerous, file disclosure, remote command execution or etc.

#ssrf #bug-bounty #zimbra #web-app-security

Story of a 2.5k Bounty — SSRF on Zimbra Led to Dump All Credentials in Clear Text
Modesto Bailey

Modesto Bailey

1594888920

Vimeo SSRF with Code Execution Potential.

Recently I discovered a semi responded SSRF on Vimeo with code execution possibility. This blog post explains how I found & exploited it. So let’s get started.

Background.

Vimeo provides an API console for their API called API Playground, The requests made using this web app is done from server-side. Take the bellow request as an example.

Image for post
Base request

This request is supposed to make a server-side GET request to

https://api.vimeo.com/users/{user_id}/videos/{video_id}

If you look closely to the request we control quite of things here, First the uriparameter which is the endpoint to hit on endpoint i.e. in this case is /users/{user_id}/videos/{video_id} , Request method i.e., in this case, is set to GET, params which are supposed to be post parameters if the request method is POST. user_id & video_id are kind of variables whose values gets defined in segmentsparameter.

Path traversal in HTTP requests made on server side.

I first tried to change URI parameter to my custom path however any change in URI will result in a 403, Means that they’re allowing a set of API endpoints. However, changing the value of variables such as user_id & videos_id is possible because they’re intentional and because these values reflect in the path of URL. Passing ../../../will result in a request to ROOT of api.vimeo.com

Below is what happens.

_URL.parse(“https://api.vimeo.com/users/1122/videos/../../../attacker”)_

Result: https://api.vimeo.com/attacker

Image for post

Path traversal in HTTP requests made on server side

As you can see in response all endpoints of api.vimeo.com is listed which is root response of api.vimeo.com if you make an authenticated request (with authorization header).

What now? We’re still on api.vimeo.com host, how do we escape it?

Well, I figured that this is following HTTP 30X redirects, Its a long story took a Lil bit of logical thinking.

Back to the point, Now I know this is following HTTP redirects and we’re good to move forward, We need an open redirect so that we can redirect server to our controlled asset.

#api #ssrf #bug-bounty

Vimeo SSRF with Code Execution Potential.