I somehow need to prove to you that I understood your article (even though it's the author's responsibility to make it clear), so let me summarize it and then point out why this is not what you think it is:
You pointed that the server had a critical vulnerability that allowed non-authorized users to perform admin actions
This vulnerability was found because attackers could easily get the UI to display "Admin controls"
This vulnerability was then fixed on the backend.
Then you elaborate on how to protect your "Admin controls" from being visible, allegation being that making them harder to find are going to make your system more secure.
For that, you implemented public-key-cryptography (in the form of RSA signatures) such that responses sent from the server are signed and then verified in the client.
The reason for implementing RSA signatures was that the server sending isAdmin: false - the flag that informs the client whether it should show "Admin controls" could then be changed to isAdmin: true by an attacker using a man-in-the-middle tool. The attacker used Burp Suite for this.
Implementing signatures made sure that changing the server responses were not possible anymore, as the public-key used for verification is pinned in the client's source code.
There are 2 things we can take from this:
The server critical vulnerability has been patched on the server. This made the application "sufficiently secure for now"
The client "Admin controls" are being guarded by a server-sent flag that supposedly can't be changed
The point other people and I are making here is that the client is in control of the user. The user can still set the flag isAdmin to true right before the code executes and that has been proved by using a simple code override in Chrome devtools. This does not mean it makes your application more or less secure - but it proves the effort you took to learn and implement response signatures might have been invested into something else. What effectively made your application secure was fixing the server flaw.
So far dozens of people understood the article very well and provided useful feedback. It is you and some other two guys who are bashing your heads against a strawman. The article seems to be clear enough.
The critical vulnerability was the hacker's ability to manipulate the UI as if he was an admin, which allowed him to use a form to create regular users, combined with his ability to spoof the request, to create a user that was itself an admin. This new user had true admin power. Fixing the API was not what made it secure, fixing the API was merely damage control. With the admin controls, finding other vulnerabilities is almost intuitive.
This is what they marked as a critical issue. People are eager to overestimate their ability to protect endpoints against unforeseen scenarios.
"and that has been proved by using a simple code override in Chrome devtools"
"Browser overrides will modify the source before it is executed"
And modifying the source won't compile a new working version. Devtools is not webpack. You'd have to change the compiled version. If you can't see the difference, maybe you're wasting both our times.
And you fail to understand that fixing the backend was merely damage control. With the admin UI, the hacker would quickly find some other unexpected way in. You clearly overestimate your ability to know what you don't know.
"Never discuss with an ignorant. They will get the discussion to their level and beat you with experience."
I'm definitely wasting my time trying to help you understand what is wrong with your thought process. I felt obligated to comment as are are articles like this that hurt security as people will naively think this will protect them of anything and it won't.
Ah, yes, one of those quotes you can turn around 180º and they still work perfectly. What will your next argument be? The one about playing chess with a pideon? It is specially ironic, since you're the one leaving before providing evidence of your "trivial break-in". You probably tried and seen it doesn't work as you expected, right? It is likely that with enough time you can figure out a way, but this "enough time" is time I am securing the backend, so by the time you find a vulnerability, it could already have been patched.
And, finally, people will only be hurt by this article if they, as you, are unwilling to read. There is a huge disclaimer before the article starts, and I discuss my skepticism of the solution itself in the conclusion.
Fixing the API would have prevented the attack completely. I don't know how the pentesters brainwashed you into thinking it was the other way around, that protecting your Front-end is what actually fixed the security flaw.
I challenge you to host a similar system with the same API flaw but with the signature obfuscation in place and let me break in.
Because "fixing an endpoint" is not the same as "making the API unbreachable". It is even weird that you can't connect these two dots. The hackers would simply find another unexpected way in in minutes.
Clone the repo, the implementation is already there and working. It even comes with a sample pair of keys, so all you need to do is install the dependencies and run.
Then prove you bypassed it. You claimed to have posted a screenshot, but I have re-read all my notifications and there are a total of zero screenshots of you breaking in. The time it took you to lie about posting the screenshot was enough for you to take an actual screenshot.
You're not disabling the signature, kid (what you said you could trivially do).
You did not prevent the signature verification. You have to disable the verification and then modify the network response to accurately represent what we're discussing.
What you did simply wouldn't work on a function that deals with all requests, your hardcoded data would instantly break the application.
I see no evidence of what you claim in this screenshot. "John Doe" is the correct data. How does this prove the validation was bypassed?
But it was valuable. Try changing it to "false". If this works, it will probably show the error message.
Working or not (it probably won't, but could, anyway would be nice to know), I expect you learned that someone with technical knowledge responding with a mere attempt after three hours of intently messing around with it (your hurt ego is clearly a strong motivation) is comfortably outside the range of "trivial". Which ultimately proved my point: it is sufficiently secured against the profile of the potential attackers: employees with no tech skills but incentives to fiddle around.
The whole point is that you do. As I explained, your other attempt would simply break everything else.
Just checking the times on the notifications from your messages we can clock you out at four hours (at least, since you're been interacting for several days at this point). That with full guidance, since I was here correcting every failed attempt you made, and disregarding the other measures in place. Thanks for taking your time into providing this very useful benchmark and proof of concept.
And I wasn't inefficient at all. I was constantly engaged in our conversation since ~6 in the morning, answering everything you said. If it took you four hours to do this with my constant guidance, then it does what it was designed to do: to protect the UI controls.
They have motivation to try. I'd say the only person wasting my time was you, but you also provided a valuable benchmark for me, so I thank you for that.
How can you be so presumptuous? I really should have let you stay in ignorance and denial but it goes against my principles.
It was a step by step process because you failed to extrapolate my ideas to the full solution. It's partially on me for not explaining them well enough.
I see. Your principles involve writing an article misrepresenting what this article claims trying to make fun of me for the crime of........ shuffles card..... asking for feedback.
You're obviously heavily invested in this. No one likes being disproven, especially with something they're proud of making. But please reconsider your attitude against someone that is trying to help.
You got humbled by technology and facts. I think my article served it's purpose.
Your article proved this measure accomplishes what it was designed to do.
I'm even tired of repeating the phrase "with enough time and effort". And voi la. It took an ego-hurt engineer half a dozen hours to do something that could work, with guidance and disregarding the other measures in place. It is sufficiently secured against our employees.
I am skeptical they could even if they did read. You made lots of jumps based on knowledge assumptions (things you don't know if other people know). That's probably the whole reason you naively said it was trivial, several hours before actually managing to do it.
Putting a padlock in your locker is not obscurity just because a skilled attacker can pick it open if given enough time.
As I responsed to that person, obscurity would be changing the name of the "isAdmin" property to "dhASDuhVNAS132" trying to conceal what it does. So implementing something like Fractal as a security measure would be obscurity.
I somehow need to prove to you that I understood your article (even though it's the author's responsibility to make it clear), so let me summarize it and then point out why this is not what you think it is:
isAdmin: false- the flag that informs the client whether it should show "Admin controls" could then be changed toisAdmin: trueby an attacker using a man-in-the-middle tool. The attacker used Burp Suite for this.There are 2 things we can take from this:
The point other people and I are making here is that the client is in control of the user. The user can still set the flag
isAdminto true right before the code executes and that has been proved by using a simple code override in Chrome devtools. This does not mean it makes your application more or less secure - but it proves the effort you took to learn and implement response signatures might have been invested into something else. What effectively made your application secure was fixing the server flaw.I don't know how I can be clearer.
So far dozens of people understood the article very well and provided useful feedback. It is you and some other two guys who are bashing your heads against a strawman. The article seems to be clear enough.
The critical vulnerability was the hacker's ability to manipulate the UI as if he was an admin, which allowed him to use a form to create regular users, combined with his ability to spoof the request, to create a user that was itself an admin. This new user had true admin power. Fixing the API was not what made it secure, fixing the API was merely damage control. With the admin controls, finding other vulnerabilities is almost intuitive.
This is what they marked as a critical issue. People are eager to overestimate their ability to protect endpoints against unforeseen scenarios.
"and that has been proved by using a simple code override in Chrome devtools"
By whom?
"Browser overrides will modify the source before it is executed"
And modifying the source won't compile a new working version. Devtools is not webpack. You'd have to change the compiled version. If you can't see the difference, maybe you're wasting both our times.
And you fail to understand that fixing the backend was merely damage control. With the admin UI, the hacker would quickly find some other unexpected way in. You clearly overestimate your ability to know what you don't know.
"Never discuss with an ignorant. They will get the discussion to their level and beat you with experience."
I'm definitely wasting my time trying to help you understand what is wrong with your thought process. I felt obligated to comment as are are articles like this that hurt security as people will naively think this will protect them of anything and it won't.
Ah, yes, one of those quotes you can turn around 180º and they still work perfectly. What will your next argument be? The one about playing chess with a pideon? It is specially ironic, since you're the one leaving before providing evidence of your "trivial break-in". You probably tried and seen it doesn't work as you expected, right? It is likely that with enough time you can figure out a way, but this "enough time" is time I am securing the backend, so by the time you find a vulnerability, it could already have been patched.
And, finally, people will only be hurt by this article if they, as you, are unwilling to read. There is a huge disclaimer before the article starts, and I discuss my skepticism of the solution itself in the conclusion.
Fixing the API would have prevented the attack completely. I don't know how the pentesters brainwashed you into thinking it was the other way around, that protecting your Front-end is what actually fixed the security flaw.
I challenge you to host a similar system with the same API flaw but with the signature obfuscation in place and let me break in.
Because "fixing an endpoint" is not the same as "making the API unbreachable". It is even weird that you can't connect these two dots. The hackers would simply find another unexpected way in in minutes.
Clone the repo and do it.
Host it, make it "unreachable" using your method and I will post here whatever you made unreachable by thinking your Front-end is secure.
Make an admin route and I can screenshot it. I'm determined to prove it to you if you give me the means.
I cloned the repo, ran a build locally and it is easily bypassable. There are no dots to connect.
Clone the repo, the implementation is already there and working. It even comes with a sample pair of keys, so all you need to do is install the dependencies and run.
Then prove you bypassed it. You claimed to have posted a screenshot, but I have re-read all my notifications and there are a total of zero screenshots of you breaking in. The time it took you to lie about posting the screenshot was enough for you to take an actual screenshot.
You're not disabling the signature, kid (what you said you could trivially do).
You did not prevent the signature verification. You have to disable the verification and then modify the network response to accurately represent what we're discussing.
What you did simply wouldn't work on a function that deals with all requests, your hardcoded data would instantly break the application.
But that's my fault, I set the bar too low. LoL 😂
It still proves my point, which you fail to see.
I see no evidence of what you claim in this screenshot. "John Doe" is the correct data. How does this prove the validation was bypassed?
But it was valuable. Try changing it to "false". If this works, it will probably show the error message.
Working or not (it probably won't, but could, anyway would be nice to know), I expect you learned that someone with technical knowledge responding with a mere attempt after three hours of intently messing around with it (your hurt ego is clearly a strong motivation) is comfortably outside the range of "trivial". Which ultimately proved my point: it is sufficiently secured against the profile of the potential attackers: employees with no tech skills but incentives to fiddle around.
The whole point is you don't need to change the server response. And even if you did, returning
truefrom the validation function would work.Again, this took me 5 minutes - it's your terribly inefficient attitude that made this take 3 hours to understand.
If you're assuming your users are not capable of attacking you, why even bothering then? It appears to me you have wasted your time.
The whole point is that you do. As I explained, your other attempt would simply break everything else.
Just checking the times on the notifications from your messages we can clock you out at four hours (at least, since you're been interacting for several days at this point). That with full guidance, since I was here correcting every failed attempt you made, and disregarding the other measures in place. Thanks for taking your time into providing this very useful benchmark and proof of concept.
And I wasn't inefficient at all. I was constantly engaged in our conversation since ~6 in the morning, answering everything you said. If it took you four hours to do this with my constant guidance, then it does what it was designed to do: to protect the UI controls.
They have motivation to try. I'd say the only person wasting my time was you, but you also provided a valuable benchmark for me, so I thank you for that.
How can you be so presumptuous? I really should have let you stay in ignorance and denial but it goes against my principles.
It was a step by step process because you failed to extrapolate my ideas to the full solution. It's partially on me for not explaining them well enough.
I see. Your principles involve writing an article misrepresenting what this article claims trying to make fun of me for the crime of........ shuffles card..... asking for feedback.
You're obviously heavily invested in this. No one likes being disproven, especially with something they're proud of making. But please reconsider your attitude against someone that is trying to help.
You got humbled by technology and facts. I think my article served it's purpose.
Your article proved this measure accomplishes what it was designed to do.
I'm even tired of repeating the phrase "with enough time and effort". And voi la. It took an ego-hurt engineer half a dozen hours to do something that could work, with guidance and disregarding the other measures in place. It is sufficiently secured against our employees.
Not if they see my article 😏 don't tell them.
I am skeptical they could even if they did read. You made lots of jumps based on knowledge assumptions (things you don't know if other people know). That's probably the whole reason you naively said it was trivial, several hours before actually managing to do it.
As someone else pointed out, this is just security through obscurity at this point.
Putting a padlock in your locker is not obscurity just because a skilled attacker can pick it open if given enough time.
As I responsed to that person, obscurity would be changing the name of the "isAdmin" property to "dhASDuhVNAS132" trying to conceal what it does. So implementing something like Fractal as a security measure would be obscurity.
But OK. Thank you.
Point is you already have a padlock. What you did was to paint "TSA Certified" on it hoping nobody would be attempt to pick it.