A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
I don’t mean to be rude, but I can’t understand what you’re trying to say.
The RSA signing code is in the front-end right. That means a hacker can malform and create their own api requests or inject a payload to modify the response since they have the signing code so it’s not a matter of them having “infinite time” it can be done in a matter of 5 minutes that’s what I’m trying to say.
For the reasons stated above is why I say secure your backend. You say it’s not one of the other, I don’t have to use your web application. Like I said I can spin up a http client, extract your RSA code and you’re right back at step 1, but I can only your 1 backend.
"I don’t mean to be rude, but I can’t understand what you’re trying to say"
Neither am I, but why bother replying in such affirmative manner if you didn't even understand? That's not only rude, its pedantic. Read the article before engaging, please.
"The RSA signing code is in the front-end right"
No. Read the article, please. The front-end VERIFIES the signature. The signing code is in the BACK END. The front-end only has the PUBLIC key.
"extract your RSA code and you’re right back at step 1"
You can VERIFY messages, you CAN'T SIGN them, which means you CAN'T CHANGE them.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
No I didn’t mean I didn’t understand your article. I understand your article that’s why I was replying affirmatively. I didn’t understand your initial reply, which seemed like abstract ideas, that’s what I was saying I didn’t understand, asked for clarification then asked you to see my side by saying “you get what I’m saying” but you took it in an entirely different direction.
My last points:
If your front-end can send request to your backend, then a hacker can too.
Using dev tools your api response can be modified NO MATTER what RSA or obfuscation is being used.
A hacker can remove this “verification” at anytime of their choosing.
"No I didn’t mean I didn’t understand your article"
But you didn't, you claimed twice that I was signing messages on the front end, which in the article itself I explain is a bad idea.
About your points:
Yes, that is why securing the API is important. This is not what the article is about. The article is about the attackers faking the responses from the API.
I have never seen this being done, but I won't say it can't be done, it probably can. But so what? The application will immediately stop working as soon as you try to change the response.
You're not the first to make this claim, and I'm not saying it can't be done, it probably can, given enough time, but how? The professional pentesters couldn't break it, and they had two full days to try, and full knowledge of how the solution was implemented. You can't simply change the source files in devtools in your browser and have the new code be executed (you can change it, but it won't reflect on the code that is actually running. Test it), that's not how any of this works.
If it can be done, it is not as trivial as you're probably thinking. Which brings us to the report's conclusion: "sufficiently secured for now".
Inserting modified code into a web application is very easy to implement using almost any proxy software. For example, we can take the same Burp Suite, intercept the js file response and replace it with our modified version.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Application stops working? It's my browser, my client. Once my client downloads your application I can do whatever I want no matter what you think. If I visit your application from my browser, it will not stop working because I won't allow it.
Anyone could change the api response to anything they want, no matter what encryption or whatever fancy thing your api is sending back because I CONTROL THE CLIENT not you. I can change your API response to whatever I want.
Yes you can change source files to whatever you want, I don't know why you think you can't, where is that idea coming from? I just did it right now for dev.to just cause I can, as I would do with your site.
Again I'm not trying to be rude, you seem to gaps in your knowledge of the browser based on your other responses and you seem to put too much faith into this backend api signing function and underestimate how much control users really have. I'm trying to tell you its trivial BECAUSE IT IS.
I want you to have a secure application at the end of the day, thats why I'm saying focus your energy to where it needs to be NOT ON THE CLIENT WHERE I HAVE FULL CONTROL and you can't do anything to stop me...
Unless... you have a secure backend 😊.
Report "Sufficiently secured for now" is more like a false sense of security.
Yeah......... you haven't read the article. Nor my responses, for that matter.
We greatly invalidated the damage you think you could cause with your "full control". Sure, you can try to change something, but then it won't work. Enjoy your "full control" over a non-working application.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Enjoy the fake sense of security which is easily defeated by a right click and inspect element! Trust me you haven't read my responses or anyone elses, otherwise you would understand the flaw by now. It's been pointed out like 3 times by previous commenters.
I am almost tempted to give you access to the development environment of the application just to watch you fail. Sadly, it would break company rules.
You haven't read the article, you haven't read the responses, but you're 100% confident you could break this doing something you don't even know you can't do (at least not in any way remotely as trivial as you're suggesting), probably because you haven't tried.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Likewise to you my friend, just remember you haven't properly refuted any claims that I've made nor anyone else have made. You just keep repeating the same thing thinking it covers all your bases and it doesn't, your change is next to useless. But I'm not the the user (gladly) so I'll leave it at that.
I would love to get the dev enviornment, please do! At Google I've seen all sorts of security protocols, even broke a few myself and seeing the details of your "front-end security" is laughable. That's why I'm warning you. But hey.
This was one of the things the hackers tried. This was, if not prevented, at least mitigated by SRI, CSP, and other measures that were already in place.
I am sure with enough time and effort they could eventually overcome the security layers. Eventually. In any case, the client is sufficiently secured for now.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don’t mean to be rude, but I can’t understand what you’re trying to say.
The RSA signing code is in the front-end right. That means a hacker can malform and create their own api requests or inject a payload to modify the response since they have the signing code so it’s not a matter of them having “infinite time” it can be done in a matter of 5 minutes that’s what I’m trying to say.
For the reasons stated above is why I say secure your backend. You say it’s not one of the other, I don’t have to use your web application. Like I said I can spin up a http client, extract your RSA code and you’re right back at step 1, but I can only your 1 backend.
You get what I’m saying? Your RSA is useless.
"I don’t mean to be rude, but I can’t understand what you’re trying to say"
Neither am I, but why bother replying in such affirmative manner if you didn't even understand? That's not only rude, its pedantic. Read the article before engaging, please.
"The RSA signing code is in the front-end right"
No. Read the article, please. The front-end VERIFIES the signature. The signing code is in the BACK END. The front-end only has the PUBLIC key.
"extract your RSA code and you’re right back at step 1"
You can VERIFY messages, you CAN'T SIGN them, which means you CAN'T CHANGE them.
"You get what I’m saying?"
Do you?
No I didn’t mean I didn’t understand your article. I understand your article that’s why I was replying affirmatively. I didn’t understand your initial reply, which seemed like abstract ideas, that’s what I was saying I didn’t understand, asked for clarification then asked you to see my side by saying “you get what I’m saying” but you took it in an entirely different direction.
My last points:
Cheers
"No I didn’t mean I didn’t understand your article"
But you didn't, you claimed twice that I was signing messages on the front end, which in the article itself I explain is a bad idea.
About your points:
Yes, that is why securing the API is important. This is not what the article is about. The article is about the attackers faking the responses from the API.
I have never seen this being done, but I won't say it can't be done, it probably can. But so what? The application will immediately stop working as soon as you try to change the response.
You're not the first to make this claim, and I'm not saying it can't be done, it probably can, given enough time, but how? The professional pentesters couldn't break it, and they had two full days to try, and full knowledge of how the solution was implemented. You can't simply change the source files in devtools in your browser and have the new code be executed (you can change it, but it won't reflect on the code that is actually running. Test it), that's not how any of this works.
If it can be done, it is not as trivial as you're probably thinking. Which brings us to the report's conclusion: "sufficiently secured for now".
Inserting modified code into a web application is very easy to implement using almost any proxy software. For example, we can take the same Burp Suite, intercept the js file response and replace it with our modified version.
Application stops working? It's my browser, my client. Once my client downloads your application I can do whatever I want no matter what you think. If I visit your application from my browser, it will not stop working because I won't allow it.
Anyone could change the api response to anything they want, no matter what encryption or whatever fancy thing your api is sending back because I CONTROL THE CLIENT not you. I can change your API response to whatever I want.
Yes you can change source files to whatever you want, I don't know why you think you can't, where is that idea coming from? I just did it right now for dev.to just cause I can, as I would do with your site.
Again I'm not trying to be rude, you seem to gaps in your knowledge of the browser based on your other responses and you seem to put too much faith into this backend api signing function and underestimate how much control users really have. I'm trying to tell you its trivial BECAUSE IT IS.
I want you to have a secure application at the end of the day, thats why I'm saying focus your energy to where it needs to be NOT ON THE CLIENT WHERE I HAVE FULL CONTROL and you can't do anything to stop me...
Unless... you have a secure backend 😊.
Report "Sufficiently secured for now" is more like a false sense of security.
Yeah......... you haven't read the article. Nor my responses, for that matter.
We greatly invalidated the damage you think you could cause with your "full control". Sure, you can try to change something, but then it won't work. Enjoy your "full control" over a non-working application.
Enjoy the fake sense of security which is easily defeated by a right click and inspect element! Trust me you haven't read my responses or anyone elses, otherwise you would understand the flaw by now. It's been pointed out like 3 times by previous commenters.
To each their own, Cheers!
I am almost tempted to give you access to the development environment of the application just to watch you fail. Sadly, it would break company rules.
You haven't read the article, you haven't read the responses, but you're 100% confident you could break this doing something you don't even know you can't do (at least not in any way remotely as trivial as you're suggesting), probably because you haven't tried.
Likewise to you my friend, just remember you haven't properly refuted any claims that I've made nor anyone else have made. You just keep repeating the same thing thinking it covers all your bases and it doesn't, your change is next to useless. But I'm not the the user (gladly) so I'll leave it at that.
I would love to get the dev enviornment, please do! At Google I've seen all sorts of security protocols, even broke a few myself and seeing the details of your "front-end security" is laughable. That's why I'm warning you. But hey.
Cheers, I won't be responding after this.
This was one of the things the hackers tried. This was, if not prevented, at least mitigated by SRI, CSP, and other measures that were already in place.
I am sure with enough time and effort they could eventually overcome the security layers. Eventually. In any case, the client is sufficiently secured for now.