Authorization Bypass Prevention

[Former Member]

Hi all,

I am an associate  basis consultant, recently I came to know that the Authorizations can be bypassed through programs. Is there any way to restrict the authorization bypassing.

Regards,

Vineet

[Former Member]

Do you mean executing the associated program using transaction from SE38? or the Z programs?

[Former Member]

hi sunil,

I was talking about Z tranx codes, in which a transaction can be done without having authorization to particular tcode.

thanx

[Colleen]

Do you have an example of what you mean?

[Former Member]

Hi colleen,

thanx for ur attention, actually my doubt is that how could we make auth checks in Z tranx codes so that the auth can't be bypassed. Unable to give any example, sorry.

[Colleen]

Hi Vineet

There are different transactions but I will limit my comment to the scope of creating a transaction to execute a program. In this case it custom transaction can be created to either execute a SAP standard program or you built a custom program and you want to execute it

In either case your security is as following:

• S_TCODE will be checked (it could be bypassed if the use is granted access to the program via SE38/SA38/etc). This is controlled by the kernel. Adding an authority check in the code can stop bypassing via SE38/SA38 to force user to have transaction.
• Additional check will occur if configured in SE93
• **All subsequent checks come back to whether the developer wrote them in the code or called the appropriate function modules/etc that have the checks
• SU25 can switch an authorisation check of system wide for a specific object so it won't matter if code has it
• SU24 can switch a authorisation check off for a specific object for that transaction so it won't matter if code has it. Adding a check in SU24 will not suddenly cause the transaction to restrict if the program does not cater for it.

There are a few other cases of 'byapssing' - for example SE97 with Call transaction but that is a bit different to launching a custom transaction direct. Also more scenarios depending on the type of transaction

**When it comes to additional checks in the code: if this is a custom program then tell the developer to add checks to the code. I find a lot of Z* programs are lacking checks because the developer never got told to put them there. If it's SAP standard it will depend on the situation but if restriction is inadequate you might need to raise an incident or have developer enhance the code (as I'm not a developer I'm getting to my limit here - so I'm linking you to Otto's document below)

One thing for sure - you can't restrict security if the program doesn't cater for it.

Anything more, you might want to go back to the person you overheard comment from and get an example. Based on that one of us might be able to direct you in the place to look at how to best restrict it.

Regards

Colleen

[Former Member]

Thanx colleen, answer is helpfull.....

Regards,

Vineet

[Former Member]

Force users to use standard transactional logic i.e. only run their authorised.  No direct access to programs, function modules & all that good stuff.  Ensure no-one has ability to debug & replace or they can hobble most auth checks.

That should give you somewhere to start

cheers

[Former Member]

Hi Alex,

Thanx for ur respose, actually I want to know if there is any way in basis so that any ABAPer who has all development right can't bypass the auth checks.

cheers

[Colleen]

Hi Vineet

I recommend you google "sap debug change access" and to learn what authorisation should not be granted to a user in Production that is allows bypassing of checks

Development systems are different as you developers need to debug change. Generally, developers should have very limited access to Production.

Regards

Colleen