Recently I have tested a couple of commercial web-based applications that send configuration details to the client-side to determine the functionality available to the user. These details were sent as XML to a Java applet or JavaScript via Ajax. So, what’s the problem?
The applications in question had several user roles associated with them, from low privilege users up to administrative users. All these users log into the same interface and features are enabled or disabled according to their role. In addition, access to the underlying data is also provided based on their role. However, in both cases, features were turned on and off in client-side code – either XML or JavaScript. One application actually sent isSuperUser = true for the administrative account and isSuperUser = false for others. A simple change in my client-side proxy actually succeeded in giving me access to administrative features.
The other application had several parameters that could be manipulated, such as AllowEdit. This gave access to some features, but I noticed that there were other functions available in the code that weren’t called by the page. It was a simple matter of looking for the differences between the page delivered to the administrator and that delivered to a low privilege user to find the missing code to call the functions. This was duly injected into the page via a local proxy again and new buttons and menus were added that gave administrative functionality enabled by manipulating the parameters sent, as above. Some might argue that this attack isn’t realistic as I needed an administrative account in the first place, but the code injected would work on every install of the application. You only need that access to one installation of the application, which could be on your own machine, then you can copy and paste into any other instance (or you could simply Google for the code).
It shouldn’t be this easy! Anything set on the client can be manipulated by the user easily. The security of a web application must reside on the server, not on the client. Web application developers must start treating the browser as a compromised client and code the security into the server accordingly.
The applications in question had several user roles associated with them, from low privilege users up to administrative users. All these users log into the same interface and features are enabled or disabled according to their role. In addition, access to the underlying data is also provided based on their role. However, in both cases, features were turned on and off in client-side code – either XML or JavaScript. One application actually sent isSuperUser = true for the administrative account and isSuperUser = false for others. A simple change in my client-side proxy actually succeeded in giving me access to administrative features.
The other application had several parameters that could be manipulated, such as AllowEdit. This gave access to some features, but I noticed that there were other functions available in the code that weren’t called by the page. It was a simple matter of looking for the differences between the page delivered to the administrator and that delivered to a low privilege user to find the missing code to call the functions. This was duly injected into the page via a local proxy again and new buttons and menus were added that gave administrative functionality enabled by manipulating the parameters sent, as above. Some might argue that this attack isn’t realistic as I needed an administrative account in the first place, but the code injected would work on every install of the application. You only need that access to one installation of the application, which could be on your own machine, then you can copy and paste into any other instance (or you could simply Google for the code).
It shouldn’t be this easy! Anything set on the client can be manipulated by the user easily. The security of a web application must reside on the server, not on the client. Web application developers must start treating the browser as a compromised client and code the security into the server accordingly.
Comments
Post a Comment