2021 OWASP TOP 1: control de acceso roto

Directorio de artículos

1. Control de acceso no válido

1. ¿Qué es el control de acceso?

El control de acceso es una estrategia Bajo el control de esta estrategia, la operación del usuario no puede exceder el límite de permiso preestablecido. Una vez que falla el control de acceso, generalmente conduce a la fuga de información no autenticada, manipulación de datos internos, eliminación de datos y operaciones no autorizadas. Los problemas de fallas en el control de acceso generalmente se clasifican en las siguientes categorías:

El sistema viola el "Principio de privilegio mínimo" o "Principio de denegación predeterminada" durante el proceso de implementación. En este caso, los usuarios pueden obtener algunos permisos especiales, y estos permisos especiales solo deben otorgarse a usuarios o roles específicos;
Omita el control de acceso modificando las direcciones URL, el estado del programa interno, las páginas HTML o el uso de herramientas cibernéticas para modificar las solicitudes de API;
Obtenga una vista previa o modifique otra información y datos de la cuenta al proporcionar una identificación única;
Acceda a la API a través de los métodos POST, PUT y DELETE sin control de acceso;
Aumento de privilegios en el sentido habitual, como operaciones de usuario en el estado de no inicio de sesión u operaciones de administrador en el estado de inicio de sesión de usuarios normales;
Manipulación de metadatos, como reproducir o modificar tokens de control de acceso JWT (JSON Web Token), o elevar privilegios mediante la manipulación de cookies;
La configuración incorrecta de CORS puede provocar el acceso a la API desde fuentes no autenticadas.

2. Escenarios de ataque comunes

Los usuarios pueden modificar fácilmente el contenido del parámetro de la URL, para que puedan acceder fácilmente a la página de administración. Las siguientes son dos URL hipotéticas. La primera es para usuarios normales y la segunda para páginas de usuarios administradores. Si los usuarios normales acceden con éxito a la segunda página, significa que hay un problema con la política de control de acceso.
```
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
```
Debido a que no se establecieron límites en los parámetros de acceso del usuario durante el proceso de implementación, se han producido muchos problemas no autorizados. En la siguiente URL de ejemplo, el atacante puede intentar modificar el parámetro order_id en la interfaz API para que la entrada en la interfaz del programa sea legal. , pero para el usuario es un acto de ultra vires.
```
https://example.com/order/?order_id=2021102617429999
```
El método HTTP PUT se usó originalmente para operaciones de administración de archivos. Puede implementar operaciones de actualización, como cambiar y eliminar archivos en el servidor del sitio web. Este método a menudo puede provocar varias vulnerabilidades de carga de archivos y ataques graves al sitio web. El código de ejemplo a continuación admite PUT In el entorno del método, cargue Webshell para elevar el privilegio; en el uso real, si se debe habilitar este método, se debe realizar un control de acceso estricto para los recursos de archivo involucrados en el método.
```
put /root/Desktop/shell.php
```
La aplicación web almacena directamente el resultado de la autenticación de identidad en la cookie y no impone medidas de protección adicionales. En el ejemplo a continuación, el atacante intercepta la cookie a través de la interfaz web para modificar la cookie, logrando así el efecto de un acceso no autorizado:
```
Cookie: role=user --> Cookie: role=admin
```
Para mayor comodidad, algunos desarrolladores reflejan directamente el valor de origen solicitado en Access-Control-Allow-Origin. Por ejemplo, la siguiente configuración significa que nginx confía en cualquier sitio web y permite todo el acceso a los recursos de lectores de dominios cruzados, lo que resulta en el robo de datos privados.
```
add_header "Access-Control-Allow-Origin" $http_origin;
add_header “Access-Control-Allow-Credentials” “true”;
```

3. Plan de reparación

Priorizar el diseño del sistema de control de acceso

访问控制不仅是应用安全设计的一项主要事务，而且应当被设置在非常优先的位置，因为往往访问控制的设计在起步阶段是相对简单的，但是会很快随着功能点的增多快速复杂化。所以，如果你考虑使用成熟的软件框架来完成访问控制，一定要确保其能够满足你未来的应用定制化需求。

Obligar a todas las solicitudes a pasar primero por verificaciones de control de acceso

可以这种方法开发一个访问控制检查层（Layer），然后确保所有请求都在某种程度上经过这个检查层。以 Java 的 filter 为例，许多自动化的请求处理机制都是能够帮助我们实现这种需求的技术形态。

Denegar por defecto

这是非常简单但是有效的策略，所谓默认拒绝是指，只要一个请求没有被指明是被允许的，那么它就是被拒绝的。

Registrar todos los eventos de control de acceso

所有的访问控制失效都应该有完整的记录，因为这些事件很可能成为恶意用户尝试寻找系统漏洞的线索。

2. Cruce de caminos

1. ¿Qué es el recorrido de la ruta?

En pocas palabras, hay un componente funcional en el sistema que usted construye que usa entrada externa para construir un nombre de archivo que se usará para ubicar un archivo en un directorio restringido si el nombre de archivo contiene ambos elementos especiales y ningún filtrado razonable hará que la ruta sea resuelto en un directorio fuera de la carpeta restringida.

Para ampliar la lección, muchas operaciones de archivos dentro del sistema quieren estar restringidas a un directorio específico. Mediante el uso de los símbolos ... y /, un atacante puede escapar de la ruta del archivo. La combinación de símbolos más común es .../, que se resolverá como el directorio de nivel superior en el sistema operativo. Esta vulnerabilidad se denomina ruta transversal relativa. El recorrido de ruta absoluto es otro tipo de recorrido de ruta, como /usr/local/bin es un ejemplo típico.

2. Escenarios de ejemplo de recorrido de ruta

Ejemplo 1:

Un código de aplicación de red social típico, el perfil de cada usuario se almacena en un archivo separado, todos los archivos se recopilan en un directorio:

 $dataPath = "/users/example/profiles";
 $username = param("user");
 $profilePath = $dataPath . "/" . $username;
// 可以发现并没有对用户传入的username参数进行验证
open( $fh, "<$profilePath") || ExitError("profile read error: $profilePath");
print "<ul>\n";
while(<$fh>) {
    
    
    print "<li>$_</li>\n";
}
print "</ul>\n";

Cuando un usuario intente acceder a nuestro archivo de configuración, se formará la siguiente ruta:

/users/example/prfiles/hunter

Sin embargo, aquí no se filtra el nombre de nuestro archivo de acceso de entrada.Si el atacante captura el paquete y modifica el archivo de acceso para solicitar ../../../../../../etc/passwddicha ruta de archivo, la ruta completa es la siguiente:

/users/example/prfiles/../../../../../../etc/passwd   ==》/etc/passwd

Provocando así el cruce de caminos.

Ejemplo 2:

Teniendo en cuenta la inseguridad de la entrada, el siguiente código adopta el método de lista negra para filtrar los ../caracteres contenidos en la entrada, pero se puede ver que -g no se usa para la coincidencia de parámetros globales:

 $username = GetUntrustedInput();
// 这里是老师写的注释
// 黑名单方式过滤
// 对username的过滤不严格
$username = ~ s/\.\.\///;
$filename = "/home/user/" . $username;ReadAndSendFile($filename);

Por lo tanto, después de que la lista negra filtre el primero ../, los siguientes ../seguirán empalmándose en la ruta para provocar el cruce de la ruta.

Ejemplo 3:

El siguiente código, aunque se adopta una lista blanca, todavía tiene el problema del cruce de rutas:

String path = getInputPath();
// 这里是老师写的注释
// 白名单方式过滤
// 对path的限制不够严格
if (path.startsWith("/safe_dir/"))
{
    
    
    File f = new File(path);
    f.delete()
}

Cuando la carga útil del ataque del atacante tiene /safe_dir/../../../../../../../etc/passwdesta forma, aún provoca el cruce de la ruta.

3. Plan de reparación del cruce de caminos

Implementación en la etapa de codificación:
- Suponiendo que todas las entradas sean maliciosas, use una estrategia de verificación de entrada "solo aceptar bien conocido", es decir, use algunos formatos de parámetros estrictos y bien definidos;
- La entrada debe decodificarse en el formato de procesamiento interno del programa y asegurarse de que no se decodifique dos veces en el sistema de la aplicación para evitar que los atacantes eludan la codificación o la codificación secundaria;
- Si es posible, proporcione opciones para los usuarios o acceda a los objetos a través del mapeo de ID interno del sistema de la aplicación, por ejemplo, ID 1 corresponde a "info.txt";
- Asegúrese de que el mensaje de error contenga solo la información mínima necesaria, evite mostrar información demasiado detallada y evite que los atacantes obtengan información relacionada con el sistema.
Implementado durante la fase de diseño arquitectónico.
- Asegúrese de que todos los controles de seguridad en el extremo del cliente completen el segundo control en el lado del servidor. El propósito de esto es evitar que los atacantes eludan los controles de seguridad en el lado del cliente;
- El uso de una biblioteca o marco maduro facilita a los desarrolladores evitar este tipo particular de riesgo.
en la fase de construcción de defensa
- El uso de un firewall de capa de aplicación que pueda defenderse contra este tipo de ataque es muy efectivo en algunas situaciones específicas (como las vulnerabilidades del sistema de aplicaciones que no se pueden reparar);
- Ejecute el sistema de aplicaciones desarrollado con privilegios mínimos y, si es posible, cree una cuenta restringida independiente para que se ejecute el sistema de aplicaciones;
- Ejecute el sistema de aplicaciones desarrollado en el entorno de sandbox y haga un buen trabajo de aislamiento de límites entre procesos y sistemas.

3. Fuga de información sensible

1. ¿Qué es una violación de datos confidenciales?

En pocas palabras, si nuestro sistema de aplicaciones expone información confidencial a un usuario no autorizado, existe el riesgo de fuga de datos confidenciales.

La fuga de datos confidenciales sigue siendo un punto de riesgo muy grave y común incluso hoy en día. La razón principal es que la fuga de datos no es un problema puramente técnico, sino que a menudo está estrechamente relacionado con los procesos comerciales y el diseño funcional.

Desde la perspectiva del grado de daño de la vulnerabilidad, la fuga de datos confidenciales se divide principalmente en dos tipos, una es la fuga de datos comerciales confidenciales y la otra es la fuga de información confidencial tecnológica. La fuga de datos comerciales confidenciales es extremadamente dañina y afectará directamente la marca y las operaciones comerciales de la empresa; la fuga de información confidencial tecnológica a menudo no representa una amenaza directa para la seguridad del sistema de aplicaciones, pero puede lograr 1+1> con la utilización integral de otras vulnerabilidades 2 efecto.

2. Escenarios de fuga de datos confidenciales

Problemas lógicos en la fase de diseño del sistema de aplicación;
Salida incorrecta del manejo de excepciones;
El interruptor de depuración no se apagó cuando se implementó la aplicación;
Se obtienen demasiados permisos.

3. Soluciones de defensa para la fuga de datos confidenciales

Debido a la naturaleza especial del riesgo de fuga de datos, la fuente del riesgo suele ser un problema de seguridad en el nivel lógico, el nivel de diseño o el nivel de autoridad, lo que dificulta que las soluciones de defensa tradicionales y los escáneres desempeñen un papel. tipo de riesgo

Durante la fase de desarrollo y diseño, se pueden considerar las herramientas de modelado y auditoría de amenazas para ayudarnos a descubrir los riesgos de seguridad introducidos en el nivel lógico y el nivel de diseño. El modelado de amenazas de las funciones del sistema y los procesos comerciales puede ayudarnos a eliminar muchos riesgos de seguridad comunes.

4. Configuración de permisos incorrecta

1. ¿Qué es la configuración de permisos incorrectos?

Permisos irrazonables En pocas palabras, es el proceso de otorgamiento de autoridad irrazonable, procesamiento de autoridad y gestión de autoridad. La autoridad mencionada aquí se refiere a un atributo del rol terminal.

Entonces, ¿qué es un rol terminal? Puede entender que un usuario es un rol de terminal. Principalmente realizamos el proceso de autorización, procesamiento y gestión relacionado con la autoridad a través de la gestión de autoridad.

La administración de autoridad es la capacidad de dar a los terminales el derecho de realizar ciertas operaciones especiales. Por ejemplo, en algunos escenarios de operación y mantenimiento, el personal de operación y mantenimiento puede obtener la autoridad para mantener el sistema, que incluye la autoridad para reiniciar el servidor; sepa que el reinicio del servidor no es una autoridad operativa de rutina.

2. Escenario de vulnerabilidad de configuración de permisos inadecuados

Escenario 1: Ejecución de servicios con altos privilegios

Durante el proceso de instalación y ejecución de componentes, la configuración del entorno operativo de algunos componentes del programa tiene permisos demasiado altos, lo que da como resultado aplicaciones con privilegios bajos que pueden completar la operación de escalada de privilegios a través de la relación de llamada de servicio. Por ejemplo, si nuestro servidor web se ejecuta directamente con privilegios de root o administrador, una vez que la aplicación web tiene una vulnerabilidad, conducirá a la adquisición directa de privilegios de root después de ser despojada. La mayoría de estos problemas ocurren a nivel de operación y mantenimiento.

Escenario 2: reducción anormal de potencia

Código de ejemplo:

def makeNewUserDir(username):
    ...
    try:
        raisePrivileges()
        os.mkdir('/home/' + username)
        lowerPrivileges()
    except OSError:
        return False
    ...

El código anterior contiene una escalada de privilegios a corto plazo, y el desarrollador disminuyó inmediatamente el privilegio después de completar la operación de destino, pero debe tenerse en cuenta que el nombre de usuario es un parámetro de entrada externo, que puede deberse a varias razones (entrada no válida, seguridad laxa). filtrado, etc.)) hace que la función mkdir informe un error y luego arroje una excepción. Una vez que esto se activa, la función lowerPrivileges no se puede ejecutar y el programa continuará ejecutándose en un estado de privilegio alto, lo que puede proporcionar una ambiente cómodo para el posterior proceso de explotación de vulnerabilidades.

3. Plan de reparación para la configuración de permisos incorrectos

Para problemas de seguridad relacionados con permisos, tenemos diferentes formas de defenderlos y detectarlos en tres etapas diferentes.

Durante la fase de diseño arquitectónico, puede usar el "principio de privilegio mínimo" para ejecutar su código y, si es posible, crear una cuenta separada con privilegios limitados para su código de tarea.
En la fase de desarrollo e implementación, debe prestar suficiente atención a los segmentos de código de alto privilegio y proporcionar políticas de restricción y auditoría más estrictas en el nivel de detección de entrada.
En la fase de configuración del sistema, para sistemas de aplicaciones complejos, debe asegurarse de que los archivos de configuración estén bien auditados, y los archivos de configuración a menudo afectan en gran medida el nivel de permisos del sistema de aplicaciones.

5. Vulnerabilidades CSRF

1. ¿Qué es una vulnerabilidad CSRF?

El nombre completo de CSRF es Cross-Site Request Forgery, y el nombre chino es Cross-Site Request Forgery. En términos simples, significa que la aplicación web no puede distinguir efectivamente si una solicitud externa es realmente del usuario que inició la solicitud. aunque la solicitud puede ser La estructura está completa y la entrada es legal.

Pueden surgir problemas de CSRF cuando una aplicación web no está diseñada teniendo en cuenta lo suficiente los mecanismos de autenticación para las solicitudes de los clientes. Desde la perspectiva de un atacante, puede usar una URL, carga de imágenes o XMLHttpRequest para permitir que el usuario active un comportamiento de envío de solicitud automático, esta solicitud se considerará legal cuando el servidor web la acepte.

2. Escenario de vulnerabilidad CSRF

El siguiente código es para permitir a los usuarios actualizar su propia información:

<form action = "/url/profile.php" method = "post">
    <input type = "text" name = "firstname" />
    <input type = "text" name = "lastname" />
    <br/>
    <input type = "text" name = "email" />
    <input type = "submit" name = "submit" value = "Update" />
</form>

Donde profile.php contiene el siguiente código:

// initial the seesion in order to validate sessions
session_start();
// if the session is registered a valid user the allow update
if ( !session_is_registered("username") )
{
    
    
    echo "invalid session detected!";
    // Redirect user to login page
    ...
    exit;
}
// The user session is valid, so process the request
// and update the information
update_profile();

El código PHP aquí contiene algunas medidas de protección, basado en lo que hemos aprendido en los cursos anteriores, incluye la autenticación de validez de la identidad del usuario y evita el acceso no autorizado. Sin embargo, el código anterior no puede prevenir eficazmente los ataques CSRF.Si un atacante puede crear el siguiente código y alojarlo en un sitio determinado, cuando el usuario permanezca conectado y visite la página de códigos de ataque, se activará el código de ataque:

<script>
    function attack()
    {
        form.email = "[email protected]"
        form.submit();
    }
<script>

<body onload = "attack()">
    // ...
</body>

Se puede ver que el código de ataque anterior contiene contenido que es invisible para el usuario cuando usa el navegador. Cuando el código de ataque se carga en el navegador, se activará la función de ataque. Si el usuario permanece conectado mientras visita el sitio web de la víctima, el sitio web de la víctima recibirá una solicitud del usuario para actualizar el correo electrónico a la dirección de correo electrónico del atacante.

A través de los códigos de ataque típicos anteriores, podemos resumir varias características de ataque CSRF:

Los ataques generalmente ocurren en escenarios de dominios cruzados.La razón principal es que el nivel de seguridad de los dominios extranjeros suele ser más bajo que el del objetivo atacado, y es más fácil de controlar para los atacantes;
De hecho, CSRF no obtuvo las credenciales de inicio de sesión del usuario durante el ataque, sino que simplemente envió una solicitud maliciosa a través de la mano del usuario;
Hay muchas formas en que los atacantes pueden usar: URL de imagen, hipervínculo, envío de formularios y muchas otras formas. caso de combate

3. Métodos de defensa para vulnerabilidades CSRF

Política del mismo origen

该防御策略的产生主要为了针对 CSRF 攻击的第一个特征——跨域场景，它的设计思路主要是禁止外域（或者不受信任的域名）对 Web Server 发起请求。在 HTTP 协议中，有两个 Header 字段可以用来帮助我们判断来源域：Origin Header 和 Referer Header。这两个字段在浏览器发送请求时会自动携带，并且不能由前端修改。

Simbólico

CSRF Token 如何实现呢？为每一个 form 表单生成唯一的 token，并且在 form 提交时验证 token，就是 CSRF Token 的实现思路，但是 token 需要保证不可预测。在代码实现上主要有 2 种思路。
第一种是在用户访问页面时，由服务器生成 Token，将生成的 Token 存放于 Session 中，一般 Token 生成时会通过加密算法实现，输入一般包括随机字符串、时间戳等.
第二种是通过JS遍历DOM树结构来插入token。

Diseño de interfaz segura

现在的防御方案，主要考虑的是如何防止跨域的 CSRF。因为攻击者无法获取到 Token，所以大家会普遍认为，本域发生的 CSRF 暂时是安全的。但是，如果 XSS 和 CSRF 问题同时在本域发生，由于 XSS 可以让攻击者获取 Token，CSRF 的防御就宣告失效。因此我们需要在 Web 应用设计和开发过程中，严格过滤用户的输入，确保用户不能够输入我们不希望出现的内容，这样可以同时规避掉 XSS 和 CSRF 安全风险。

galleta doble

在 Web 应用开发中新增 CSRF_Token 机制还是稍有些麻烦，那么我们该如何通过现有的组件，来实现 CSRF 防御方案呢？答案是双重 Cookie。
当用户访问 Web 网站时，Web 应用为用户随机生成一个新的 Cookie 值，当 Web 应用每次执行表单提交操作时都需要携带这个 Cookie 值；由于同源策略的保护，攻击者无法获取或者修改这个 Cookie 项，因此实现了 CSRF 的保护。