Can firebug or developer tools be used to hack a website?

I came across an interesting problem when implementing a specific role on a website.

Something like this, if the registered user has privileges for the administrator role, then the button (called Transfer) will be enabled , and for the other user it should be disabled (Thus, they cannot click, therefore, they cannot complete the transaction / or call the appropriate logic for this)

At first glance, it seems pretty straightforward UI checking some things. We just need to enable the button if the registered user has administrator privileges.

So, after implementing this approach (works great), I debugged the code using the Chrome developer tools. I noticed that although the button is now disabled, we can actually enable it by deleting the disabled part with the tool.

Just try with this simple violin

And then I can click on it and the functions will be called. In principle, this was not a very good approach. But, fortunately, there is also a validation of the parties to the service. But if this cannot be a huge security vulnerability.

So basically doing a server / service / back-end check will prevent something dangerous. But since a person can actually click on it, and at least he can try to call methods that seem not to be nice :(

So, I would really like to know how we can prevent such situations.

ok, here my question is simple:

Is it good to have components disabled at all?

+5
source share
5 answers

Do not use disabled components in your view.
This part of your business logic should not appear in the DOM ...

"But hey :))"

Now even this element does not exist, nothing can prevent the user from manually introducing such an element to your site.
You should always perform server-side checks to see that such a user has actual privileges to perform a specific action .

Sometimes the user interface uses disabled elements to display the user:
"Hey, look at this button? It's not for you unless you pay or blah blah,"
but usually as a second step / optional action item .

Sometimes whole forms are β€œvisible” on websites, but disabled / disabled .
Such use cases are: Payment forms with steps, when the designer wants to make it desirable for the user that he needs to fill out the previous form in order to β€œActivate” the second and continue the payment, etc ... The cases are endless, but if on the website there is a form, pure UI (View), and the model should never take values ​​from the controller, unless (as I said) was set by business logic.


Remember that Front-end Javascript is used only to inform and assist the user through intuitive interface systems. JS events should only be there to reflect what the user can and cannot.

Since JS can be bypassed by any high-performance user, on the back you need to rebuild a similar and more reliable security logic once again.

(!) Confirm the user input on the interface, but most importantly - in the background.


Can I use firebug or developer tools to hack a website?

Directly ?

  • Yes
    • If the logic of the website can be used by controlling the presentation (source).
    • If you store in the code that gets into the browser (in the comments, etc.), confidential information.
  • No
    • If a website does not allow XSS, it is well protected.

Indirectly ?

The malicious user may ultimately ask the user to open the console (trick the user that the Console is the actual function of the website) and send him (copy / paste) the personal information present there , such as session keys, cookies, etc. d.

+4
source

When the request is received by the server, you should check if this is really because I managed to get the button to work in less than 10 seconds.

0
source

Depending on the server-side programming language, you can use templates to create your HTML pages so that components that are not allowed to specific users are not even displayed in the first place.

For Java you have JSP / JSTL or JSF, for .Net you have ASP.Net and MVC.

0
source

You should fully check everything related to logins / permissions on the server side. Even if you change the site so that instead of disconnecting an element that you never attach to the DOM, first of all, the technician can just try to send different data to your server and extort for a meaningful answer using wget or curl

0
source

How do you prevent such situations? Should you disable the components?

The answer to the first question gives you the answer to the second question.

You should not do this on the client side. However, this is a common case, and it is always recommended that you have server-side checks so that people using developer tools can work around these things.

Another approach, in addition to not realizing this, is to abstract it.

If the user is not logged in, he did not even include the button in the DOM. When they pass the specific parameters needed to give them a button, you can use javascript to query the server side, check this and then enter the button accordingly, even then you should have another server side query checking the action after the button is triggered.

  • Display options for execution parameters
  • Confirm
  • Enter button
  • Trigger button
  • Validate
  • Perform action

It really depends on how your application is laid out. In fact, if you do not include the first two steps and only hide the button before checking, your UX application does not change if the developers are not part of your audience because developers love to break things.

Can I use firebug or developer tools to hack a website? If the application data was not protected or verified on the server, then yes.

You should always check the incoming data and check it regardless of the source of external or internal.

Validation is your friend.

0
source

Source: https://habr.com/ru/post/1236742/


All Articles