Server-Side Cross-Site Scripting - Balazs Bucsay

Um so welcome to serverside cross-ite scripting. My name is Balaj Buch and I'm going to bore you a little bit with my life. So over the two over the past two decades I um was doing offensive security and in the past 15 plus years uh mainly I was focusing on consultancy and research. I'm also a software reverse engineer. I just had a workshop yesterday uh here underground. Uh I started to learn assembly when I was 13 years old and then uh I had quite a lot of fun with that. Um for fun I go around the world and do different talks on different conferences. I've been to the US couple of times uh obviously around Europe and

even in the APEC region, Philippines, Singapore and Australia. Uh, I think I'm quite a um friendly guy. So, if you want to to chat with me after the talk, I'm up for it. I'm going to be here for lunch for sure. Um, here are a few topics that you can start the conversation with. Obviously, IT security, that's why we are here. But other than that, I love to do sports and um, traveling as well. I've been to more than 75 countries so far. And my soft goal is to go around the world and visit every country. Um yeah, fun fact, I collect the length of the temps last year. I went from the source to

Greenwich and uh I spent like 9 to 10 days on the river. You can find me on Twitter on on um LinkedIn as well. And same goes for my company. Just send me a request or follow me uh if you like. So that's me on the temps under the tower bridge which was pretty cool. It gives a different view of the city for sure. A little bit about my company. I started Mont information security almost two years ago. It's a boutique consultancy. We do all kind of IT security services including penetration testing, web application, web API testing training delivery. We have a really cool training. It's called software engine reverse engineering. Um we can teach you

how to do reverse engineering from scratch in a few days. Um yeah, so hit up the website if you are interested in one of these services or the training uh or just reverse engineering in in general and you will find a few uh bits of information about the company and me. Yeah. So let's talk about the the gist server side cross-ite scripting which might be a strange one. This is definitely a mouthful. Uh it's hard to to even pronounce it to say it. Uh so let's talk about that a little bit. First of all, I would like to start with cross-ite scripting. Everybody knows cross-ite scripting. This is the most well-known uh attack vector vulnerability out there. And I'm

pretty sure this is one of the most misunderstood as well. If you see this window, you have cross-ite scripting on your website. This is usually how it's presented in uh in in reports. So, what's cross-ite scripting? Basically, it's a type of injection attack. If you have a website and you can inject uh malicious or any kind of HTML JavaScript into the into the website, then you have uh cross-ite scripting issue. There are different types. I'm not going to talk too much about cross-ite scripting in general, but there are stored, reflected, and DOM based and it's always executed in the browser. But that's the question is it always executed the browser? Is it a yes? Is it a no? Um so

there are basically three different root causes why you have uh cross scripting in your website and if you choose one of these and implement one of these you won't have this issue. So improper input validation improper input valid input sanitization or improper output sanitization. If you have all these if you have all three missing from your website then you will have input validate input uh injection issues including cross-ite scripting. If you implement one of these three, not the improper ones, the proper ones, then you will be safe against these kind of attacks. So I told you that cross-ite scripting is one of the most misunderstood um injection attack out there and the reason why because nobody understands

the impact behind that. So whenever we are talking about a report that is um created by a consultant like me probably I'm not the best example for this but uh anybody who is doing consultancy usually find these kind of issues and create a report then they just put that alert one or similar window into the report. You get a screenshot and they tell you that you have a cross-ite scripting and we can create a window out of your website. So you wouldn't really understand what's the impact behind that if you're not technical, if you're not a security consultant or a geek. Uh which is fine. Not everybody's like that. But the point is you can do a lot more than that.

Obviously a consultant doesn't always have time to do full impact. But there are a few other things that you can do. Well, quite a few other things that you can do from cross-ite scripting including user impersonation, account hijacking where you can steal the cookie. uh you set that cookie in your browser as an attacker and you can impersonate the user. You are logged in. You don't need the username. You don't need a password. Sometimes you don't even need a second factor authentication if the website requires one. You can do whatever you want with the impersonated user which is a bigger impact than having a window on the website. Right? So that speaks for itself. You can do

website defacement. You can just redress the UI. You can change the pictures whatever you like. You can do everything from JavaScript if we are talking about a website and there is always the fishing attacks as well. So if you are working for a bank, if you have a uh organization which is attacked by scammers, attacked by by by runomware operators and whatever and they can do defacement, they can find the cross scripting on your website. They can do fishing attacks against you. So they send an email, you click on the link because it points to your website that you trust. And if there's a cross-ite scripting vulnerability in your website, they can redress it. They can put some

kind of login form on your website and they can get your username and password if you type it in and you might type it in because it's a trusted website. It's your website, but if there is a vulnerability in that, they can control the content, right? So that's that's a lot bigger impact than just having alert one window in your browser. So again these kind of vulnerabilities cross-ite scripting most of the time it's really really trivial to find um and that's why it's really misunderstood and underestimated. So I al also mentioned that it only affects the client's browser right well we are going to talk about that in a bit. So I want to be

sure that you understand even though I'm talking about JavaScript and HTML I'm going to talk about cross-ite scripting mainly uh well purely this is something else. So I purposefully choose the title for this talk to be um serverside cross-ite scripting instead of JavaScript injection because JavaScript is everywhere. So obviously we have it in websites we have it in web servers. So if you think about NodeJS, you can create websites on the server side from from NodeJS which is based on JavaScript or there is electron and you can use JavaScript to create desktop applications, right? Well, I'm not going to talk about these things but I wanted to mention it here. So basically if you can do

JavaScript injection in websites you get cross-ite scripting. That's what I'm going to talk about. But there is um JavaScript injection in NodeJS where you can do remote command execution or in desktop applications electron where you can do remote remote command execution again from JavaScript. So there is quite a variety between uh behind the JavaScript injection but we are going to talk about the first thing uh cross-ell scripting in web applications. So I mentioned already that uh cross scripting runs in the browser on the client side, right? Is it always the case? Well, not always the case because sometimes the browser runs on the server, which is quite a strange thing to think about, but it happens. So why

does it happen? Uh there are multiple reasons but the main reason that I find these days is that more and more web applications have this feature where there is a button and when you click the click on the button you get a PDF and that PDF will have the same website or part of the website. If you think about your internet banking, you can log in and you can see your statement, right? And there is a button to download your statement and you get a PDF file which is going to have all the the spending and income uh transactions that you have um incoming transaction that you have in your bank. So you get the same content

in in a web browser and you can get the same content in a PDF if you push a button. So somehow that PDF needs to be created and there are multiple ways to do that. Um in the past it was more like developers started to to understand how PDF works, HTML, how to render that uh using a software library but that took a long time. Um so there's a different approach to do that these days and this is more like the agile approach where you move fast and break things. Probably heard that already. But with the issue the issue with this approach uh and the diverse technology stack that we have out there that developers just copy

paste everything from everywhere use parts from here and there and for example if you think about this this uh technology set uh stack docker chrome and html if you think about docker um that's a wellestablished technology it's quite secure obviously you can misconfigure But by default it's quite secure. There is Chrome which is one of the most secure browser out there browsers out there. And there's HTML which is a well established standard. It's with us for a long time and it's going to stay with us for a long time. And there is PDF as well which is like it's okay but let's say it's it's secure right? So if you add these three and you

get PDF out of it and everything is secure then the solution should be secure as well right? That's what you would think but most developers don't think about these things because they are not security specialists. So um they make mistakes. So my approach is probably the the first one but that's not how the world works anymore which is fine. But my point is that uh with the faster pace and with this agile approach and moving fast and breaking things, we definitely break security as well and that's not helping our uh our environments. So I seen this in in real life multiple times. I had these issues uh in quite a few engagements so far. So

I was thinking maybe I can do a presentation on it. and a good presentation. Well, uh I like to have a presentation with with demos usually. So I put together a demo and here what's going to happen is basically I created an environment in AWS Amazon web services u where there is a website where where you can submit HTML content and you get a PDF pack. is going to run on Docker, ECS, Fargate, ECR services if you if you want to know it in in uh in depth and there is a little bit more in the background that I'm going to talk about. So um I was looking into these docker solutions where you have this uh

dockerized container that you can use to generate PDF from HTML. One of the first uh Google um results that I found was this export HTML GitHub repository. You can find it really easily if you Google it. And it was perfect for for my for my reasoning for this presentation. It's a Docker container. It does what I want it to do. It basically creates an API that you can post HTML into and it returns a PDF to you. So what could go what could go what could go wrong with it? Right? Well, we will see that. But before I go into the details, I want to uh note something here. So if you open this repository, it it hasn't changed.

There is a oneliner security notes which I find really cute. This is totally right. Uh I I fully agree with it. It says this is intended to run as a micros service. do not directly expose it to the public internet and that's a really good no right you shouldn't expose it to the public internet but the issue with this is just a oneliner so there are quite a few other things that you could add for example I would disable JavaScript I would put it put this docker container into a fully isolated firewall environment so it wouldn't be able to access anything else on the network and also you might want to validate and sanitize all inputs that

are going into the container, right? Because I told you if you have improper input validation, input sanitization and output sanitization, then you are going to have issues. So, uh I like to be fair. So, I went on GitHub and I opened a new issue about security implications and I detailed that maybe that oneliner security note which is quite cute should be expanded a little bit. here are the things that I would put in there. Maybe you can do a little bit of research on that. And I understand that nobody has the responsibility in this case. But if you expose some if you publish something on the internet uh because you want to help people, you might want to do the extra

mile and add a few extra security features because people will get those containers. They just going to clone the repository and they will use it as is. they won't care about security and the more people use the same same repository that is vulnerable the more issues we are going to have in different products. So yeah, um I didn't expect much from from this uh issue that I opened actually. It uh it it it worked out really well. I got two likes. So that's that's basically the implication. Um well that that's the impact that I managed to got uh from it. And also I need to note that one of the likes is is uh was by myself. So that's that.

Uh so what I did I created an environment uh which I thought is going to be really trivial but if you use cloud products then you might realize that uh this is not that straightforward if you want to do it um quick actually I I don't think you can do this quick. So I created IM roles, policies, VPCs, subnets, routting tables, internet gateways. I deployed two different containers with ECS with Fargate and I configured quite a few security groups as well uh to have this environment for for for this presentation. Uh there are two containers I already told you one is the export HTML with that you can render PDF from HTML. Uh not that surprising.

And the other one I built a custom one just to make it more enjoyable and just to to uh make it more real life. Obviously this this custom build is is was um it was purposefully built vulnerable. So it doesn't really count but you can find the same issues in in in the wild in real life. So I I wasn't really cheating there. So the customuilt one has two different issues. One is LFR local file local file read. So you can read any file uh with that vulnerability from the local file system. And the other one is SSRF which is server side request forgery. So you can send um HTTP requests to any services on the network

or maybe to the internet as well. So let's see the demo.

Sorry, too many windows. But this is the website. I don't think you can access it. Uh this is the docker container. And um this is usually what you see, but if you know a little bit more about this uh I thought I changed it or it didn't change the one. Oh.

Okay, maybe let's see the video for this one.

So here you have the the Docker container that I was talking about. It's working. is accessible from the internet and in Burp you can send a post request to it. So that's what I'm going to do. This is the endpoint and you can see the content there which is HTML body hello. It it's uh it basically creates a website which says hello there. Now we send it. It says 200. Okay. So it was generated and you can see it's a PDF file. That's the content. It even says that it was built it was created on Linux and it's a headless Chrome. So basically a Chrome browser without a GUI. And if you save the content that was

returned into a PDF file, you can open it in a browser. There you go. And that's the rendered PDF, right? So from HTML, you could create a um PDF file which basically the same content that you would expect in the browser. So that's what I wanted to show you in Burp, but didn't work out really well because of the the font size. And then there are different payloads that you can try against. So I have a set of payloads here. Can you read it in the back? Perfect. Thank you. Yeah. So this payload is basically another HTML. All the payloads are going to be HTML and JavaScript. This one creates an iframe that points to my website mont

oneinfosite.com and going to load an HTML file. So I wrote a script. It doesn't this is the script. It's just going to help me to execute uh these payloads is going to be sent to the server uh in in JSON format. So here in the terminal, I'm just going to send to that IP payload one. Okay, that that happened. And in the five view, you can see there's a PDF file. So when I open the PDF file, you can see this frame here because it's an iframe. And inside the I frame I have my logo and a bit of my website. So what does that prove us? Basically it proves that the um that the browser the headless Chrome

browser on the server side has internet access. It could I could connect to my own server from that docker container. So basically I can render any website from that docker container. uh from the web from the internet right so the next thing that I want to check whether it it it has J JavaScript enabled so what I'm going to do I'm going to use that payload or a similar payload oops not that one payload two so you you might see this uh it's a script it's a JavaScript where we write some content into the website. It's basically it's going to be a number and if you execute it and you see the number you will you can be sure that uh

JavaScript is running on your com on on in the browser so it's not disabled. Let's say payload 2 and that's the number right that's basically what we expected. So now we know that it has external internet connection and it it runs JavaScript as well. So let's see the um

back to the slide. So we know that basically we can do cross-ite scripting on the server side. We can render any kind of HTML and JavaScript whatever we want is going to work. So what can we do from h from from a browser? What what can we do with JavaScript? What can we do with cross-ite scripting? Right? So there are quite a few things. For example, you can reference SMB shares and you can do SMB relaying or um you can capture the hashes. Uh other than that you can do SSRF port scanning you can access cloud related metadata read local files probably maybe sometimes and uh do denial of service. So the first thing is this one only works on Windows.

So we saw that the the the Docker container is running on Linux. Uh it was in the PDF header. So this is not going to work for us. But if the Docker container runs on Windows for some reason or we have a similar situation on Windows, you can do SMB relaying or you can steal the hashes and you might be able to log into the server. So that way you can do uh remote command exe remote command execution on the server right away. Obviously, it's not that trivial, but you can do that. Uh, in our case, it's not going to to work uh because it's running on Windows. There is another one, local file read, which

might be really useful if you are using Linux. Uh, you might be able to to read file like etc password or etc shadow depends on the privileges that the browsers has. Well, this only works if the same origin policy um allows it. So what's same same origin policy? Basically if you um when when you try to open a file or a website, it only allows you if the the origin is the same as the the target. So here you can only read files if the the payload comes from the file. So if it's if whatever I send to the server to the docker container is written into the file into a file and that file is being opened by the

headrest chrome browser then you can do local fire rate local fire read. I need to note that uh about blank doesn't count as a file. So um we will see later whether we have local fire read or not. I'm going to do the demo for that. There is denial of service that you can do but I prefer not to do that because it it makes no uh point for me. I don't like to do harm but if you are evil or you are a blackhead hacker or runover operator you might want to do this and you can create a huge financial impact uh on the on the owner of the uh AWS resources. There are quite a few ways to

do that. Okay. Okay. So the next one is cloud metadata. Hands up if you heard about these. Okay, some of you. So basically if you are using clouds uh GCP, uh AWS or or um Asia then you have these metadata host. It seems to be universal between these three across these three cloud providers. the metadata can be useful uh and it sometimes it stores really really important and useful information like username, passwords, different credentials, private keys and so on. So if we are talking about AWS, you have the metadata under that um IP, right? There are two different ways to uh to access it. The the first one is EMDS version one. This is the old one.

they try to um deprecate it because they realize it's not a good idea to have it like that. Basically, it's a simple respend request response method. So, you send a request to that website and it returns the the value. So, it's really simple. There is the EMDS version 2 which is a newer version. This is pushed on uh everybody now which is a more secure version. Here you need to send a put request first. you get back a session ID um and then you need to send that section ID as an extra header with the the default follow-up get request. So the thing uh with this that you can't do this from HTML itself you can kind of

do that from JavaScript but because of course uh it's not going to render and it's only re relevant on EC2 um and we are using ECR which is for Docker containers. So let's check the next payload that I have payload 3. So this is going to give us the window location. Oops.

So the window location is about blank. This is important because of the same origin policy. I told you that if it's a file name, a local file name, you will you will be able we will be able to read files from the local file system. If it's about blank, that's not going to work. So, we know that we don't have local file read unfortunately, which would be a quick win for us, but that's not the case. Um then payload 4 that I haven't shown you yet is basically pointing to the cloud metadata service under that um URL. And as you can see here in an iframe there is this uh set emoji. So it couldn't load. That's not going to work.

It's not running on EC2. So um that's uh not that surprising. So next slide on GPC Azure again it's the same IP uh it's it's a little bit different you need to put an extra header into the get request um different for Asia and GCP but again the issue with this for us as attackers as hackers that because of course it's not going to render in the browser so one really interesting thing about AWS and ECS docker your containers uh containers in general that there is a there is another metadata host under that different IP right so um you can you can easily open that in an iframe and I'm going to show you we can get the

metadata but if you want to get more juicy things like uh credentials then you need to have the GUID which is a unique identifier quite long for the container and it's not that easy to get that but if you can get it then you can get the credentials. So how do you get that? It's basically you go into that file and you read the content of the file. But I told you that we don't have local file read. So how do we solve that? So let's see the next payload which is five and then six. I'm going to execute those payloads on the server and render it to a PDF. So this is five and this this is a JSON

content uh right this is returned as a JSON this is the metadata for um for the container and the cloud and the the cluster you can say the cluster name here which might be useful if you do attacks on the cloud environment. Um what else then? Uh yeah, so IP IPv4 address that's quite important. 227 we might want to remember that. That's an internal IP address that we can attack later. And let's see the oops not this one. Apologies. Yeah. So a lot more information about about the container itself. It might be useful. It might not be useful for further attacks but it's definitely not that great that we have that there. So um what else can we do?

Port scanning is one of the things that we can do. So the the the container is running inside of the AWS environment right. So uh if we manage to discover other IPs, other ports in the same environment which is an internal environment, we might be able to to find other vulnerable services and do more harm uh to the environment or you we can just jump across and and uh get more details, credentials and so on. And that's our that's our goal. So we can do kind of we can do poor scan from HTML from JavaScript from cross-ite scripting. And there is a really really cool research under this URL by done by Nikolai Chair. I'm not sure if I said

that name correctly, but big ups for the guy. He was using um websockets and images, image tags to to do port scanning from HTML and JavaScript. It's based on timing. So um it's not super reliable, but it kind of works. And also Chrome and other browsers figured out that maybe this is not the way for to go forward. So they tried to fix these issues by introducing random noise, random delays into the process. So uh even though this is a really cool research, it not always working as intended. But there is the old school way uh that you can use. You can use iframes and you can just include different website from the internet network into iframes. Obviously, it only

works for HTTP and HTTPS. So, that's a limitation. Uh, but what you can do, you can check check for timeout. So, let's see a demo on that. This is basically the script that I stole from the um from the website that I mentioned. It's quite complex. Um, that is the internal IP that I'm going to use just to speed up. I know there is something listening on that service on that IP on port 8080. So I'm going to execute that payload. But if you are more interested first of all you should read that URL that I put it on the slide. But otherwise this is the script that I just formatted in a different way

because otherwise it wouldn't run. Okay. So let's execute that seven.

And basically it tells you that the port is open. Right? So um I I'm not going to bore you with the port scanning bit because it takes a little bit of time. But the next thing that you can do is to read the content of that web page. So I told you that you can use iframes to do that if it's HTTP or HTTPS. So this is an iframe pointing to the website. It's like a CTF right now. So let's just do eight and I do nine as well just to speed this up. And eight it basically shows you the content of that website that we found on the internet network. And it says that's

why I said it's like a CTF. It I give you the answer for the next step. Basically there is an endpoint called LFR local file read where you can specify a file name. So what I'm going to do I'm going to try to read the etc password file from the docker container. Let's see whether that works or not. I already executed the payload. So payload 9. And you can see that returned the etc password files content which is quite good. So what would be the next step? Right, we want to read the proc self environ file because that has the GUID for the container. So payload 10 is putting the same website into an iframe

but with a different file name that proc self and environ um contains the GUID that I mentioned to you and with the GUID we can get the the session token and other stuff as well. So there you go. This is the uh the content of that file. And here it tells you that AWS container credentials rel relative URI is is under that one. So I'm going to copy that. This is the GUID. I need to make sure that it's copied properly because it's not always working like expected.

Okay, that looks to me good to me. So, um other than reading local files, you can do SSRF with this service. And uh I mentioned to you that ECR Docker uh ECS sorry has a different metadata um host IP and that's the IP for the metadata if you are talking about ECS and under that if you know the GUID which we got from that local file then you can get the juicy bits the credentials. So I just executed that payload as well. And there you go. If you are familiar with this, basically this is what you get back uh from AWS if you're lucky. It has quite a few things. Uh let me just copy this.

We need to format it. So there is the access key ID and we have the secret access key. Those are the main things that we need and the token. So the token is a bit badly formatted because of the new lines. I need to format that which takes a little bit of time.

Okay, that might be it.

Just give me a second.

It took some time. Sorry about that. Uh what happened here? Basically, I exported everything in my console. So I can use the um AWS command to do anything on the cloud that I can do. Um, and here I use the STS get caller identity command. And you can see that I'm basically logged in. Uh, the next step would be to figure out what I can do with the cloud uh with the cloud at all because it might be restricted. Usually it isn't. So let's just see.

So there is this uh really cool tool that you can use to enumerate your credentials and uh your roles and polies policies in AWS. You can see that basically I have access to everything

uh including e uh s3. So I can read the buckets, I can uh list the buckets, I can create new buckets, download files and everything. There is only one bucket here which is called only for admins. We are definitely not admins by default but with these credentials we are. So yeah I can list the content of that pocket as well. There's a secret that text file. I'm really curious what's in that secret. So um let's just try to get it. And basically the content is I hope you like the presentation a AWS owned by owned via serverside process scripting.

Yeah. So that was the the demo. Thanks for um coming along with this. Basically the last bit I want to talk about is the mitigation bit right um how to fix these issues. I already mentioned to you that to fix basically any kind of injection attacks but specifically cross-ite scripting in this time uh you need to implement one of the three uh input validization one of the following three things input validation input sanitization output sanitization if you have at least one of the three you are going to be fine you don't need to worry about these kind of issues on a high level approach You can do more than that and you should do more than

that. So first of all you can do and you should do threat modeling where you sit down you think about the issues that might uh happening with your with your solution. It doesn't have to be this exact solution anything in general. So you just think through if you were an attacker how would you attack the the environment? What would you do? Um and you need to consider different angles here. When you have all the angles that you can come up with, you need to find the uh mitigation techniques that you can implement or the fixes that you can implement. If you do that, you are going to be more protected than ever. There is the lease privilege principle and

separation of duties. These are really important. You could see that this cloud user that I use that I abused had access to everything, right? So obviously it doesn't have to to access everything. Why would you need access to S3 and EC2 services in AWS if you are Docker container? That's very little. It doesn't make too much sense for me. And the separation of duties as well. If you have two different roles, you shouldn't merge it into one user. You should use two different policies, two different users. um just to make sure that even if one gets compromised, it won't be able to abuse the the um privileges, the permissions that it it was um assigned

to, right? And um defends in depth. So segregation firewalling um in this case, the container had access to the public internet. You could download everything. you could load uh render any websites from the web from the internet um and also not just from the internet but from the local network as well. Why does it need to have access to the metadata? Why does it need to have access to to other local services? So if you had proper segregation uh if we had proper segregation in this case then we wouldn't be able to access the the other docker container which was vulnerable for local fire read and uh server side request forgery. Um back to the HTML to PDF I kind of gave you

already answer to this what you can do with this uh to make it more secure. First of all you should reconsider using these kind of technologies in full. uh it's really hard to make them secure and probably the best way to go forward is not to use them at all. But obviously it's not the case, not always the case. You can't just drop a feature request whenever you like. So what you can do in the Chrome browser, you can disable JavaScript that going to help big time. Um you can configure uh like in general settings to make it more secure and you should run it in fully envir fully isolated segregated firewall environment as I mentioned before and um you can do

HTML with embedded stuff. So even if you need pictures you can embed it into the HTML. So you don't need to have access to to the public internet or to the local local network. You can put everything in one file in one payload. And if you can do that, do input validization and sanitization. But I think I mentioned that too many times in this in this presentation already. Uh there was this other container which which had the local file read. I put that there because I wanted to make a nice demo uh show you the full attack chain from one cross-ite scripting which has usually no impact. Basically you can own the whole cloud environment and this

happened be previously. So even though this is a madeup environment just for this uh presentation, I had this issue like the exact same issue in the wild and I could own um a few companies like this. So that was the presentation. If you have any questions, uh I think we have time to do that. Nick

Thanks Balash. That was really interesting. Uh in terms of detection for this uh for are the normal burp fuzzer payloads enough to to bring back something that will let you know this is there or would you need to provide your own more specific payload? >> Sorry I missed the the first the first bit of the question. So what about the detection >> uh for detection of this? So are the are the standard B fuzzer payloads enough >> or would you need different kind of detection customized? >> Okay. So I I thought that different kind of detection. So if you are that attacker whether you can find it with automated tools that's a question isn't it?

>> Yeah. >> Yeah. I'm I'm not totally sure whether you have this in in Burp. Uh well, basically here you had a JSON payload and also I'm I'm not sure whether uh Burp can render and detect PDF content. So I I would say no, you wouldn't be able to access it. Uh you wouldn't be able to detect it with the Burp by default. Thank you. Any other questions? No. Well, thank you so much for coming. It was a pleasure to be here.