Quantcast
Channel: SCN : Document List - ABAP Development
Viewing all articles
Browse latest Browse all 935

Hiding Keys in URL Parameters with ABAP

$
0
0

Hy everyone,

 

i'm waiting for a transport request to get into the test system. so i thought i'll quickly write a document about hiding key informations in urls with abap. let's assume you have a web application, where you want to display some invoice information.

 

Very often you see constructs as the following:

http(s)://domain.com/someapp/index.html?invoiceid=<BUKRS><BELNR><GJAHR>

 

With this information a user that knows a little bit about sap & sap objects sees that the key is a concatination of key fields from a table. with such kind of parameters it's pritty simple to get other content as propably previewed by the application developer, just by increasing for example <BELNR> in the key. With such kind of parameters it's pretty clear, that the user can manipulate application results.

 

as it is a good practice to mask such kind of keys, i would like to describe two pretty simple solutions to avoid such kind of parameters.

 

Option 1 - My prefered approach - are GUIID's

Usually i create a mapping table with the following structure. All fields are set as key's in se11.

mandt - guiid - <BUKRS> - <BELNR> - <GJAHR>

 

Afterwards, an this is for both options the same, i implement a little abap class with following functions:

get_guiid() - This method takes care of the generation of a guuid (solved with SAP standard classes within) - just don't try to generate own guiids by a custom alghorithm or other approaches.

get_business_key(exporting iv_guuid) - This method returns the "real" db key to a given iv_guiid. iv_guiid could be the parameter invoiceid of the url on top of this document.

get_guuid_from_key(exporting is_business_key) - This method returns the "masked" db key to use it e.g. as url parameter.

 

With this simple approach, it's quite impossible for the user to manipulate url parameters.

 

Option 2 - MD5Hash

It's pretty much the absolute same approach as option 1, but it works with MD5Hash as equivalent to the guuid in option 1. It has one advantage for me. With a given set of information e.g (<BUKRS><BELNR><GJAHR>) i always get the same MD5Hash. With this, some kind of validation would be possible. There are function modules available in SAP Systems to generate MD5Hash values (SE84 to search with *MD5* as search string - pick a fitting function module).

 

I often use Option 2 with MD5Hash values, when i develop a programm, that could have pretty heavy business impact, if it's executed without the necessary care at the selection screen where parameters and ranges are set. The programms are e.g. reports, that correct a certain information on a table entry. i haven't wrote much of these programms so far, but it happend. I kind of implement a passwort prompt in the report to avoid unwanted execution of a certain program (e.g. a correction report). In the report, there is only the MD5Hash set as constant to wich i compare the "passwort" prompt MD5Hash value. For me, this is kind of a extended check to the sap auhority & role concept, as there is sometimes that one person, who has the right to execute any programm.

 

Think about the user bapi to assign user roles (tip: always read user roles into itab, append/remove roles to assign depending on your business logic, and only after that assign user roles by bapi -> as standard behaviour is: remove all roles, assign roles -> if you forgot to read the roles in advance, existing user role assignment is lost - happend & led to a system restore . An i'm sure there are some developers using that bapi, and after some testruns there no more developers from system perspective) A similar constellation is possible, if a program is executed without the necessary care at selection screen.

 

i wish you a nice day & hope this little document inspires ABAPers to think about hiding key values in the url.

 

Regards,

Michael


Viewing all articles
Browse latest Browse all 935

Trending Articles