In previous article, we talk about how to get data from account bank number in mobile banking application. In this article, we talk about how we help them to fix this serious security flaw.
Indirect Reference Map
An indirect reference map is a substitution of the internal reference with an alternate ID. It is used for mapping from a set of internal direct object references (i.e. database keys, filenames, etc.) to a set of indirect reference that can be safely exposed externally. In the cases of mobile banking mentioned above, attackers can make use of the exposure of easily predictable direct references to retrieve records that do not belong to the current logged in user. The direct references are CIF that are integer and auto-incrementing, or account number that you can find everywhere.
An indirect reference map can be implemented as follows:
- Create a map on the server between that actual key, account number, CIF in the database (i.e. 1011, 1012, …, ), and the substitution, which can be a long hash value or a GUID that is easily generated but difficult to predicted by users.
- The account number, CIF is translated to its substitution key before being exposed to the UI.
- After the substitution key is returned to the server, it is translated back to the original account number, CIF before the record is retrieved
Secure Both Request And Response Packet
To secure connection between client-server, it must be use HTTPS, they do it but they don’t use certificate pinning. So I can use Burf Suite or Charles Proxy with device which installed certificate to intercept all request and response packet.
Further, they make request struture very well, encrypt using timespan, session, CIF,.. but forget to secure response packet. All response packet is in plain-text, using XML structure. An attackers can capturing and modified response packet, in this case is change response account number to account number they want to get information. So we recommended they make custom response packet to secure communication.
Validate User Inputs
Always check user input before using it because evil input is the root of cause of this threat. There must be validation performed in server side, since client-side validation cannot guarantee evil input to be avoided. For instance, attackers may make use of proxy tools to capturing and reissuing requests to bypass the client-side validation, or they can re-programming all function in application and take new control flow to get something.
Use user or session indirect object references
This approach can be used to prevent attackers from directly targeting unauthorized resources. For example, use a drop down list of resources authorized instead of database key for the current userto limit the user input. The application has to map the per-user indirect reference back to the actual database key on the server
Access Model Diagram
- Grey boxes is user or session
- Green boxes are intended to be mapped for the user or session
- Red boxes are restricted assets