# Subresource Integrity (SRI) Bypass

***

## **🔍 Fundamentos do SRI**

### **O que é Subresource Integrity?**

O **Subresource Integrity (SRI)** é um recurso de segurança que permite aos navegadores verificar se os arquivos que eles baixam (como scripts JS ou estilos CSS) de servidores de terceiros (fontes externas como CDNs) não foram alterados maliciosamente.

### **Como funciona no HTML**

O desenvolvedor fornece um hash criptográfico do arquivo no atributo `integrity`.

```html
<script src="https://cdn.exemplo.com/library.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>
```

### **O Processo de Verificação**

```mermaid
sequenceDiagram
    participant B as Browser
    participant S as Servidor/CDN
    
    B->>S: Solicita library.js
    S->>B: Retorna library.js
    Note over B: Browser calcula o hash do arquivo recebido
    Note over B: Compara com o valor no atributo 'integrity'
    alt Hashes coincidem
        B->>B: Executa o script
    else Hashes diferentes
        B->>B: Bloqueia a execução (Erro no console)
    end
```

***

## **⚔️ Cenários de Bypass e Vulnerabilidades**

O SRI é uma defesa robusta, mas não é infalível. O "bypass" geralmente ocorre por falhas na implementação ou por explorar como o navegador processa o conteúdo.

### **1. Falta de SRI em Scripts Críticos**

O cenário mais comum não é um bypass técnico do algoritmo, mas a ausência da proteção em vetores onde ela deveria existir. Se um atacante compromete um CDN e o site alvo não usa SRI em todos os scripts, ele pode injetar código malicioso.

### **2. Erros de Configuração de CORS**

Para que o SRI funcione em recursos cross-origin, o atributo `crossorigin="anonymous"` (ou `use-credentials`) é obrigatório. Se o servidor remoto não enviar os headers CORS adequados (`Access-Control-Allow-Origin`), o navegador bloqueará o recurso mesmo que o hash esteja correto, ou o desenvolvedor pode acabar removendo o SRI para "consertar" o erro.

### **3. Injeção de Atributos (Dangling Markup)**

Se houver uma vulnerabilidade de injeção de HTML parcial antes de uma tag script legítima, um atacante pode injetar atributos que "confundem" o parser do navegador.

***

## **🔧 Técnicas de Exploração**

{% stepper %}
{% step %}

#### **Técnica 1: Manipulação de Cache e Service Workers**

Se um atacante já possui um XSS persistente ou conseguiu registrar um **Service Worker** malicioso, ele pode interceptar a requisição de rede e servir um script modificado sem que o navegador valide o SRI original em certas condições de roteamento interno.
{% endstep %}

{% step %}

#### **Técnica 2: Bypass via "Script Gadgets"**

Esta é a técnica mais avançada para contornar defesas como CSP e SRI.

* **Conceito:** Em vez de tentar carregar um novo arquivo malicioso (que seria bloqueado pelo SRI), o atacante utiliza uma biblioteca legítima e já assinada com SRI para executar código.
* **Exemplo com Knockout.js:**

```html
<!-- Script legítimo com SRI -->
<script src="https://cdn/knockout.js" integrity="sha384-..."></script>

<!-- Payload injetado que usa a lógica interna da biblioteca -->
<div data-bind="click: function(){ alert('SRI Bypass via Gadget') }"></div>
```

{% endstep %}

{% step %}

#### **Técnica 3: Ataque de Colisão de Hash (Teórico)**

* Embora extremamente difícil com SHA-256 ou SHA-384, se uma aplicação utilizar algoritmos obsoletos (como MD5 ou SHA-1, que não são suportados pelo padrão SRI atual mas podem ser forçados em implementações customizadas), ataques de colisão poderiam permitir trocar o arquivo por um malicioso com o mesmo hash.
  {% endstep %}
  {% endstepper %}

***

## **🚀 Bypass via Script Gadgets (Exemplos Práticos)**

Bibliotecas comuns que podem ser usadas como "gadgets" para ignorar a restrição de "não carregar scripts externos novos":

| Biblioteca    | Vetor de Bypass                                                               |
| ------------- | ----------------------------------------------------------------------------- |
| **AngularJS** | Injeção em expressões `{{ constructor.constructor('alert(1)')() }}`           |
| **jQuery**    | Uso de funções como `$.getScript()` através de handlers de eventos existentes |
| **Bootstrap** | Manipulação de atributos `data-target` para injetar HTML/JS                   |

### **Exemplo de Bypass com AngularJS**

Se o site carrega o Angular com SRI corretamente, mas permite injeção de texto no corpo da página:

```html
<!-- O arquivo é seguro e validado pelo SRI -->
<script src="/js/angular.min.js" integrity="sha384-..."></script>

<!-- O atacante injeta isso no HTML -->
<div ng-app>
  <img src=x onerror="this.parentNode.setAttribute('ng-click', 'window.alert(1)')">
  <div ng-click></div>
</div>
```

***

## **🔍 Detecção e Ferramentas**

{% stepper %}
{% step %}

#### **1. Verificação Manual**

No console do desenvolvedor (F12), procure por erros de rede como:

`None of the "sha384" hashes in the integrity attribute match the content of the subresource.`
{% endstep %}

{% step %}

#### **2. Automação com Python**

Script para identificar scripts sem SRI em uma página:

```python
import requests
from bs4 import BeautifulSoup

def check_sri(url):
    response = requests.get(url)
    soup = BeautifulSoup(response.text, 'html.parser')
    scripts = soup.find_all('script')
    
    for s in scripts:
        src = s.get('src')
        if src and not s.get('integrity'):
            print(f"⚠️ Script sem SRI: {src}")
        elif src and s.get('integrity'):
            print(f"✅ Script com SRI protegido: {src}")

check_sri("https://site-alvo.com")
```

{% endstep %}
{% endstepper %}

***

## **🛡️ Mitigação e Prevenção**

{% stepper %}
{% step %}

#### **1. Implementação Universal**

Não use SRI apenas para bibliotecas de terceiros; use-o para todos os scripts críticos, até mesmo os locais se você utiliza um sistema de build moderno.
{% endstep %}

{% step %}

#### **2. Geradores de SRI**

Sempre utilize ferramentas confiáveis para gerar seus hashes:

* [srihash.org](https://srihash.org/)
* Via OpenSSL:

```bash
cat library.js | openssl dgst -sha384 -binary | openssl base64 -A
```

{% endstep %}

{% step %}

#### **3. Combinar com Content Security Policy (CSP)**

O SRI protege contra alteração de arquivos existentes. O CSP protege contra a injeção de novos scripts.

```http
Content-Security-Policy: script-src 'self' https://cdn.confiavel.com; require-sri-for script style;
```

A diretiva `require-sri-for` obriga o uso de SRI para todos os recursos especificados.
{% endstep %}

{% step %}

#### **4. Monitoramento de CDNs**

Utilize ferramentas de monitoramento para ser avisado se o hash de uma biblioteca que você utiliza mudar no upstream, o que pode indicar tanto uma atualização legítima quanto um comprometimento.
{% endstep %}
{% endstepper %}

***

> O SRI é uma camada de defesa. Ele impede que um atacante que comprometeu seu fornecedor de JS afete seus usuários, mas não impede vulnerabilidades lógicas no seu próprio código.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/tecnicas/web/front-end/subresource-integrity-sri-bypass.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.