1 2 3 7 Previous Next


97 Posts

For the two people that have not heard of the OpenSSL Heartbleed-Bug yet, let me start with a short explanation (taken from Heartbleed Bug):


"The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users."



So, is that a serious issue? Hell yeah! To quote Bruce Schneier: ""Catastrophic" is the right word. On the scale of 1 to 10, this is an 11."


You will see lots of people recommending you change your passwords on all https:// sites. While that is generally something that you want to do now and then (in my case that would probably require me to take a week off...) _right now_ is probably not the time (yet).


Let me explain:


  • If one of the sites you have an account on is affected by the issue, data from the site may have leaked, including session data, cookies or your password (although in the individual case that is highly unlikely). Also, depending on how their landscape has been set up, their SSL keys may have leaked.
  • This means that it _might_ be the case that an attacker has the SSL keys and can use it to de-crypt the communication and sniff your new password, too. In order to fix that the site has to request & install a new SSL server certificate _and_ declare the old one invalid by revoking it.
  • Unfortunately your browser will ignore that revocation by default. Which is why you should check the settings as described in this blog: http://www.macobserver.com/tmo/article/dealing-with-heartbleed-what-you-need-to-know/P5
  • The last step is to wait for the site operator to either notify you or check on the web site that they have done the first two things (patched OpenSSL & renewed SSL certificates) - only then the site can be considered secure again!


While you're at it, it's probably also a good idea to renew any oAuth authorizations you may have given on thoise sites (like, allowing your blog to automatically post to Twitter).


This is going to be a loooong painful process for everyone. But there's no point running in a blind panic now. There's a lesson in there for everyone, I guess.

Edited on 2014-04-11 to address some of the comments:

There are two main messages I want to get across:

  • If you're changing your password before the site is fixed it won't hurt. HOWEVER, you will not be safe until it _has_ been fixed, and you will have to change it again then.



Other recommended blogs to read while you're waiting:


Creativity is bad.


On Passwords



Today I was reviewing some events generated for the Security Audit Log and noticed an interesting behavior.


For those who are not familiar with it, the Security Audit Log (SAL) allows SAP security administrators to keep track (via a log) of the activities performed in their SAP systems. In a future post we will discuss how to enable and configure this logging.


By default the SAL facility logs the “Terminal Name” which is either the Terminal Name (defined by the computer which performed the logged action) or the IP address of the computer that is the source of events. The IP address is only logged if the source computer does not transmit a Terminal Name with its communications.


This behavior can be abused by an attacker since filling the terminal name value in an RFC call is a task performed by the caller (the user’s machine). Having the ability to manipulate the “Terminal Name” means the attacker could try different attacks such as bruteforce attempts but have each transaction appear to come from a different terminal. Taken even further; the attacker could set an IP address (or cycle through a set of IP addresses) as the Terminal Name; meaning each request would appear to have originated from these IP addresses (as in the logs it is not possible to distinguish between an IP address that has been logged because no Terminal Name value was transmitted vs an IP addressed that has been logged as the Terminal Name).




To fix this problem it is possible to configure the profile parameter “rsau/ip_only” and set it to 1. In this scenario whenever possible the source IP address of the event will be logged and the Terminal Name value is ignored. This change must be made to the profile file, it cannot be done using transaction RZ11.

For more information check the SAP note 1497445

Here is the situation:


  • You come to a new customer
  • You don't want to change anything in already existing systems
  • You don't want to depend on anything but your own scripts and tools.
  • You want to get an overview of the security settings quickly.
  • ...or you are simply curious...


SUIM is a powerful and flexible tool to determine the effective authorizations a user has. It has it's quirks and if you don't know about them, you may come to the wrong conclusions. However, if you have an audit program with hundreds of checks, executing SUIM manually is not feasible.


It would be great if you could run a simple SQL statement to determine which users are authorized to perform a certain activity. However, this is not as easy as it sounds. What we need would be a table, that contains the Username, it's assigned authorization objects and their values. If we had this, we would be able to easily retrieve all authorizations assigned to the user and look for the critical ones.


Unfortunately such a table doesn't exist (except the buffer tables but depending on the system configuration the buffers may not be up to date and get rebuild as soon as a user logs on). Let's see how we get there. These are the relevant tables:


  • USR02: Contains the user logon information including passwords, lock status, validity date and so on.
  • UST10S: Describes the single profiles and the authorization objects they contain
  • UST10C: Describes the composite roles and which single roles they contain
  • UST04: Connects Users with their profiles. It can either refer to single profiles or contain the names of composite profiles.
  • UST12: the actual values of the authorization fields


And this is how they are related to each other:




Let's download the relevant tables into your favorite desktop database. There are tons of options on how to accomplish this. For example here: Import tables directly into Access from SAP using RFCs or this one: RFC_READ_TABLE data into MS Access (along with the table structure)


Let's start our process by creating a table that contains the username, profile name, authorization object and the name of the profile as it's stored in the user master record. The SQL statement may need to get adapted for your platform:


insert into denormalized ("MANDT", "BNAME", "PROFN", "OBJCT", "AUTH")

select b."MANDT", b."BNAME", a."PROFN", a."OBJCT", a."AUTH"

  from "UST10S" a,

       "UST04" b

  where b."MANDT" = a."MANDT"

    and b."PROFILE" = a."PROFN"

    and a."AKTPS" = 'A';


It creates a new table and inserts the values we need into it. The next step is to resolve the composite profiles into single profiles and add these values:


insert into denormalized ("MANDT", "BNAME", "PROFN", "OBJCT", "AUTH")
select a."MANDT", a."BNAME", c."PROFN", c."OBJCT", c."AUTH"
  from "UST10S" c,
       "UST10C" b,
       "UST04" a
where a."MANDT" = b."MANDT"
  and a."MANDT" = c."MANDT"
  and a."PROFILE" = b."PROFN"
  and b."SUBPROF" = c."PROFN"
  and c."AKTPS" = 'A'
  and b."AKTPS" = 'A';


Composite profiles in UST10C may refer to other composite profiles. That means, the field SUBPROF contains another composite profile instead of a single profile. That means, we need to add an additional level:


insert into denormalized ("MANDT", "BNAME", "PROFN", "OBJCT", "AUTH")
select a."MANDT", a."BNAME", c."PROFN", c."OBJCT", c."AUTH"
  from "UST10S" c,
       "UST10C" b,
       "UST10C" d,
       "UST04" a
where a."MANDT" = b."MANDT"
   and a."MANDT" = c."MANDT"
   and a."MANDT" = d."MANDT"
   and a."PROFILE" = b."PROFN"
   and b."SUBPROF" = d."PROFN"
   and d."SUBPROF" = c."PROFN"
   and c."AKTPS" = 'A'
   and b."AKTPS" = 'A'
   and d."AKTPS" = 'A';


We need to proceed and add additional levels until no further records can be found. As a next step we need to map the records in our table denormalized to the actual values in table UST12. A view would be the easiest and fastest:



    SELECT denormalized."BNAME",







      FROM denormalized INNER JOIN "UST12"

        ON denormalized."MANDT" = "UST12"."MANDT"

       AND denormalized."OBJCT" = "UST12"."OBJCT"

       AND denormalized."AUTH" = "UST12"."AUTH"


And there it is, the view that allows us to easily retrieve the the users that have a certain combination of authorization objects and values using SQL. This statement shows the usernames with access to SE16:



  from "V_USR_UST12"

where "OBJCT" = 'S_TCODE'

   and "FIELD" = 'TCD'

   and "VON" = 'SE16'


However, nothing is ever as easy as it seems... Let's say we have a user that is allowed to execute any transaction and thus has a "*" in the VON field. Our simple SQL statement from above will not return that user.


Another challenge is the query when an authorization object consists of multiple fields. Like for example S_DEVELOP with ACTVT=02 (change) and OBJTYPE=DEBUG.


To get around these issues you need to get creative with your SQL statements. It's not too hard and I don't want you to rob you of the fun of figuring it out


You may want to join the results to other USR* tables for example to select only unlocked users or retrieve first names, last names, departments, office locations and so on.


Often, after the project is completed, there's a need to display the system and configuration in Production server for data analysis.

To achieve this, we can adopt existing SAP_ALL profile and adjust it so that user access the system in display mode only.


Many SCN posts tell you to export the role to notepad, and then change the "ACTVT" field value to "03".

Well, this is not entirely true. You may got decent working role, but since you are not dealing with only one activity code, you can't ensure that your role will work flawlessly across departments in your company.


Common display activity codes are 03, 04, 08, 09.

Some modules uses 27, 28, 29, 53, 54, A5, etc.

You can check table TACT to list all display-related activity.


Having said that, you won't know either whether an ACTVT field can have value 03, 04, both, or all values except to browse the field one by one and maintain it manually.

This is a very time consuming process, but in the end you can finally have a reusable role that work across your projects.

Good news is, I have gone through this and you can download the role below.

It has been validated using table AGR_1251 and contain only display values across tons of object.


System: ECC 6.0 EhP7

two pans of pizza were harmed during making process


Download this File

I've been working in SAP support for over ten years and have worked the majority of this time in supporting security related topics. However it isn't true that old dogs can't be taught new tricks ! Recently I was faced with some SSO (Single Sign On issues) in relation to calling transaction SOLMAN_CENTER (and also lets throw in SOAMANAGER as well for good measure).


If you've used this you will know that when the transaction is called this will open either a HTML session in SAPGUI using SAPGUI HTML Control. However in these cases the user was presented with a request to enter user and password rather than being seemlessly brought through to the transaction via SSO (user should not need to enter a password).


In this particular case the user expected that a html session in windows sapgui would be opened however of course this was not the case and the user was presented with a logon screen. This mechanism works using a special logon ticket described in note 612670 - SSO for local BSP calls using SAP GUI HTML Control. In such a case the user calling the transaction should be a dialog user as other user types cannot be issued with the required logon ticket. This is normally the quick solution where the issue is faced.


However I wanted to check if the required logon ticket was being issued to the user and this is where the new trick (kudos to my colleagues in development support for this tip) came in.


Using report SAPHTML_SSO_DEMO the issuing of this logon ticket can be tested in the AS ABAP server. To actually trace the process you will require a http trace tool - on this case I used Fiddler which can be found on the web. Simply enable the fiddler tool and then run report SAPHTML_SSO_DEMO to generate the logon ticket issuing process.


The screenshot below details the report ran successfully and the http traffic is at the same time recorded - here we can see the BSPs called by the report


Taking a deeper look at the http trafic we can see the MYSAPSSO2 cookie is recorded as being issued. This confirms that the Logon ticket has been issued by the system


I know, there are tons of discussions here on SCN about SAP_NEW but it still seems to be widely unknown how to use SAP_NEW correctly. Therefore I try to give a summary in this blog.


First of all let's separate SAP_NEW from SAP_ALL


Authorization profile SAP_ALL is a composite profile containing generated authorizations for nearly everything.


SAP_ALL get's generated automatically whenever you transport authorization objects.


You can generate SAP_ALL using report RSUSR406 or transaction SU21. This generates SAP_ALL only in the client where this report is executed. You can generate SAP_ALL using report AGR_REGENERATE_SAP_ALL. This report generates SAP_ALL in all clients.


The customizing table PRGN_CUST contain some switches to control the generation of SAP_ALL - however, the default values are quite reasonable:


ADD_ALL_CUST_OBJECTSYES (default), NOGive full authorization for customer authorization objects (namespace Y, Z) in the profile SAP_ALL
ADD_OLD_AUTH_OBJECTSNO (default), YESGive full authorization for obsolete authorization objects (class AAAA) in the profile SAP_ALL
ADD_S_RFCACLNO (default), YESGive full authorization S_RFCACL in the profile SAP_ALL (Do not activate this switch!)
SAP_ALL_GENERATIONON (default), OFFGenerate SAP_ALL profile in after-import method for authorization objects (Note 439753)


Principal rule: No user - except maybe for highly secured emergency users - should be assigned to authorization profile SAP_ALL. This rule applies for all clients.




The authorizations in SAP_NEW exist to bridge the differences in authorization checks between releases while you are preparing the upgrade. SAP_NEW enables your business processes to continue functioning until you have incorporated new authority checks in your old authorization concept. The authorizations within SAP_NEW are bound to software component SAP_BASIS. Only if you upgrade SAP_BASIS you need to bother with SAP_NEW.

SAP_NEW  should never be required in productive systems.


There is no need to give somebody SAP_NEW if this user already has SAP_ALL. Well, you still see this combination quite often in real system, but this is simply an indicator that the administrators didn't got the rules of the game yet.


How to use SAP_NEW correctly


Prerequisite: The technical release upgrade was executed in an upgrade-preparation system.


  1. Using transaction SU02 remove all old single profiles from composite profile SAP_NEW up to and including the profile which matches to the upgrade-start-from release of software component SAP_BASIS.
  2. If SAP_NEW is now empty you’re already finished
  3. Assign the reduced authorization profile SAP_NEW to all users in the upgrade preparation system. Now all users can continue working as before the upgrade. (This step can be omitted if you manage missing authorizations while testing the upgrade using some other methods.)
  4. Inspect the authorizations in all remaining single profiles from composite profile SAP_NEW which have a higher release than the upgrade-start-from release of software component SAP_BASIS and identify the productively used roles which should get these authorizations.
  5. Adjust the authorizations in your productively used roles using transaction PFCG and remove the corresponding authorizations from the single profile of SAP_NEW using transaction SU02.
  6. Continue step 4. and 5. until authorization profile SAP_NEW is empty, than remove SAP_NEW from all users.
  7. Proceed with the preparation of the release upgrade using transaction SU25 and your own roles but without SAP_NEW.


Update since basis release 700:


Authorization profile SAP_NEW has been replaced with a generated role called SAP_NEW, too. You generate role SAP_NEW using report REGENERATE_SAP_NEW. This way, old authorization data as described in step 1. above are omitted automatically. See Note 1711620 for details.


Basically, the old authorization profile SAP_NEW and the new role SAP_NEW serve the same purpose and are based on similar data.


Authorization profile SAP_NEW is based on a list of authorization objects stored in table TOBJVOR and authorization values stored in table TOBJVORDAT.


Role SAP_NEW gets generated by report REGENERATE_SAP_NEW only using the list of authorization objects stored in table TOBJVOR but ignores the values given in TOBJVORDAT. Instead of this, full authorizations "*" are added for all authorization fields.



I don’t work much with roles and authentication. I normally just want to get all the required roles and send information to the authentication person/group that something is missing. So this may be obvious to some of you authentication gurus, but hopefully it can enlighten someone else. If I’m wrong is some areas please comment.

At my current project, we needed to have all roles as custom. I did not know how the roles works on java, and how clients uses this data. I decided to spend a few minutes on learning more on the topic.

We want to make a call to the proxy engine on Java. So we need to have the role SAP_XI_APPL_SERV_USER on the user that calls the proxy. My initial thought was the application was checking for the role name.

This was fortunately not the case. Hopefully it I is just me, who have done it a few times. The applications from SAP is checking on capabilities. The look like the following.

Role actions.jpg

There does not seem to be a copy button on the role. There is an export, modify and import functionality. Watch the 3. minutes video to see how it works.


The error message SSF_KRN_SIGN_BY_AS with return code 5 indicates a signer error, i.e., the system cannot find the correct certificate to sign or to verify the signer of some digital signature. Unfortunately, often the application running into this error message does not identify itself, so it is up to "guess" where the problem originally comes from...


The reason for this problem can be:

- Missing or wrong configuration/customization

- Missing or wrong certificate

- Problems with security toolkit installation


What would be the steps to verify that?

- Check the PSEs in transaction STRUST used to digital signature. Look there if there is no expired certificate or any inconsistency in the PSEs.

- Check if there is any useless entry in transaction SSFA (in current client and client 000). From my experience, this is the most common I've faced dealing with customers.


Therefore, the main question to find that out would be:

What applications do you have in your system that are indeed making use of SSF? Make sure that they're maintained correctly and delete the applications which are not making use of SSF.


I hope this can be helpful for at least an initial analysis.


Best Regards,

Guilherme de Oliveira.

Hi Guys


This is my first blog ,Please excuse for any errors.




SQVI queries are personalized queries and are not visible to other users.

If you want to make your SQVIquery available to other users as well, below is the process I learned.





Can create user groups using SQ03, so that you can assign the query to that group and make it available to the users.


In this example I have created a group TEST


To Do


Execute the SQVI tcode.




Click on SAP Query





Please go to Environments---Query Areas ---select Standard area.







Now to go to Query---Convert Quick View








Enter the Name of the Query and name of the infoset






Now Assign the users to user group TEST ( in this case) using SQ03




Check mark the Test Group and click save




Now users can go to SQVI


Click on Sap Query, and then go to Environments---Query Areas ---select Standard area.


They can see the query and execute as well.




I hope this helps for beginners ,

On https://service.sap.com/securitynotes -> News you can find a new spotlight news from 12.11.2013 about Security Notes concerning the SAProuter:

Important security fixes for SAProuter; new malware variant


This news refers to security notes published back in May 2013 and older but which are still open in many customer intallations. The underlying security vulnerability is named in various publications, e.g. in this one on the RSA Conference in Singapore in June 2013: The State Of SAP Security 2013: Vulnerabilities, Threats and Trends from Alexander Polyakov.


You run at least one SAProuter installation within your DMZ which is connected to the internet:


Within this blog here I like to summarize the instructions how to secure the SAProuter. Please feel free to comment on this blog to support me in improving this documentation.


Most important activities:


  • SAP recommends to upgrade any (active) SAProuter installation as soon as possible
  • Activate SNC to encrypt the communication channel to SAP support
    (or use hardware encryption using IPSEC)
  • Use an access control list (saprouttab) to limit connectivity


As the SAProuter is an independent and compatible piece of software you can update it without touching other parts of the Kernel - in fact most of the active SAProuter installations are installed on other servers than the application servers of any ABAP system anyway. Therefore SAP recommends to use the latest release everywhere. Currently you can find the releases 7.20 and 7.21 on http://service.sap.com/patches using the search. However, I assume, that release 7.20 perfectly works fine.


Note 1921693 explains how to get and update the SAProuter.

Caution: In opposite to an update of the saprouttab which can be done without restarting the SAProuter (option -n) any active connection will be stopped while replacing the executables.


Neither the EWA / RSECNOTE nor the application System Recommendations in the SAP Solution Manager can tell you if your SAProuter installations are up to date as both tools have only access to the Kernel version (disp+work) of the ABAP system itself. Therefore you have to find any outdated SAProuter installation by yourself. If you have configured the SAP Solution Manager to manage SAProuter installations you can use transaction SOLMAN_SAPROUTER to find installations which are known by the SAP Solution Manager.


These security notes are part of the latest version of the SAProuter:

  • Note 1820666 - Potential remote code execution in SAProuter
    An attacker could possibly exploit SAProuter in order to take control of an SAP application, including viewing, changing, or deleting data.
  • Note 1663732 - Potential information disclosure relating to SAProuter
    An attacker could possibly discover information relating to SAProuter connections if SAProuter is used for Internet communication, and if it is started with the option "-n". This information could be possibly abused to specialize attacks against the application server.


Architecture with IPSEC (hardware based)



Architecture with SNC (software based / certificate based)




Additional Notes:

  • Note 1895350 gives some more recommendation on the secure configuration of SAProuter
  • Note 1853140 describes the recommendation from SAP not to use the remote administration option of the SAProuter.
  • Note 48243 explains how to integrate the SAProuter into a firewall.


Online Help:


Documentation on SMP:




These documents all together propose additional activities:

  • Change the default port
  • Use an SAProuter password for SAP Support


If you are running SAP Solution Manager 7.1 you have additional options to monitor and manage the SAProuter.

Note 1886060, this wiki and this blog describe how to setup and configure System Monitoring in the SAP Solution Manager 7.1 for SAProuter.



Kind regards

Frank Buchholz

Active Global Support

Sometimes I come across roles within the SAP system that are setup and assigned as a display role. However, when further analyzing the roles it seems that the roles are not really display roles (any more). The first focus while setting up display roles is probably removing the non display ACTVT values for the corresponding authorization objects. The list of ACTVT values and meaning of the values can be found in table TACT.


No * value  and no non-display values should be given to the ACTVT value in a display. This seems logical, but sometimes only the 01 and 02 values are removed and the other critical (*) values are forgotten.

ACTVT is used by many authorizations object. The list of these objects can be found in table TACTZ.


ACTVT however is not the only authorization field that should be changed to display values, there are others as well like PPFCODE, AUTHC in HR and JOBACTION in Basis. Make sure the values that are assigned to the object fields are really only display. And while testing the role, make sure you perform both positive and negative testing.

And last, if you assign multiple  roles to one user, make sure the combination of the display role and non display roles gives not broad access rights.

My daily job is a combination of security and ABAP development. I have blogged about both the topics a lot, but not about the intersection of both the disciplines. I only realized this now. Funny.

Let’s concentrate more on this intersection today and what that very often (from my experience) means for the customers. Not exclusively of course, but way too often customers put an equal mark between the term “application security” and the AUTHORITY-CHECK statement in ABAP. So let’s concentrate on the AUTHORITY-CHECK statement for a moment. I will make the today’s blog more of a checklist with some pointers than a book type story, but that should also work for you I hope.


The basic things (MUST-HAVE)

First of all if you’re not an everyday user of the AUTHORITY-CHECKs in your code, always do the following things (they worked for me in the early days VERY WELL!!). Don’t question these, just do it! The advanced tips and tricks come later.


  1. Realize that security does not “just happen”. You must code your AUTHORITY-CHECK to protect your data and business logic. There are exceptions to the rule though, checks that are performed by the SAP kernel, but that is so rare that you should always think about security as if that is a hard work you must do, not some magic that “just happens”. Something like with the change documents. You must code the thing so that it runs.
  2. Read the help for God’s sake! This one sounds very obvious right? Unfortunately people don’t do obvious things. Go to transaction SU21, find your object and read the documentation. Hint: Documentation IS NOT for the slow. It is for those that want to do the job well.
  3. c) When you’re in SU21 reading the definition of the object (fields etc.), note that there is a WHERE-USED list button at the bottom of the popup. Use it often! It will become your new best friend for AUTHORITY-CHECKS. SAP knows what they’re doing and they do it (reasonably) well. What I am trying to say is that if you do it the way SAP is doing it you will probably code an above-average check. I have seen lots of custom code and if everyone went for this “above average option”, the quality and security of the checks would explode through the roof. And that would make the world a better place (…and more secure at the same time).
  4. When you actually code the authority-check (so you’re in the development workbench right now), use the pattern button, hmm? Way too often there is a typo or the developer forgot a field or something like this and the AUTHORITY-CHECK is there, but not doing anything.
  5. Handle the return code. I have mentioned that already and will be mentioning that a lot in this blog and all those coming in the future – security does not just happen. That includes the belief that when you code the AUTHORITY-CHECK, your code is secure. It is not. You MUST REACT to the return code of the check and do something about it. If the AUTHORITY-CHECK says the user is not authorized, you must kick the user out of the transaction (read: “inform the user nicely, return the transaction to a consistent state, but decline the access”). Handling of the return code does not “just happen”.  When you use the pattern button in the development workbench, the pattern logic will add the return code (SY-SUBRC) check for you. Complete it and sleep better in the night.



The intermediate things (also MUST-HAVE)

  1. Get yourself familiar with the concept of a DUMMY check. Help.sap.com will help you with this one the best I guess. Just briefly: you use special keyword DUMMY when coding an AUTHORITY-CHECK without being interested in values of all the fields. Example: you want to see if a user is authorized for ACTIVITY 03 for object XYZ and the object has 4 fields. Then you check ACTVT field value 03 and for all the other fields you use DUMMY. Example of a DUMMY check follows (it illustrates the DUMMY and has nothing to do with the 03 ACTVT example above).auth_dummy.png
  2. Why is it important to use DUMMY? One of the things where it helps a lot is with the developers that think they’re smart and they can build something fancy around this AUHTORITY-CHECK. Instead of using DUMMY (typically because they don’t even know about it), they start inventing DUMMY values. They invent values which then don’t exist in the domains behind fields, values that one cannot authorize for in PFCG roles etc. Don’t be inventive, ok? Use existing values for checks. Sometimes Creativity is bad.
  3. Let me emphasize this one more time: use field values that make sense (that exist in domains, in data etc.). Do not invent “your own little authorization concept just for this application”. Understand that what you hardcode in your programs must then go to the PFCG roles so the users can use your programs and transactions. That means two things: If your security administrator does not call you, he/she gave the access you’re checking in the code. If the admin calls you to say this check can’t stay in this form, it is probably because the check is too strong and forces the admin to give that access to users which in turn means that the users can then use the same access in the standard tools. And that is something the admin does not want. That should help you understand why you need to change the coded checks afterwards.
  4. The former can lead to various problems like you start creating custom authorization concepts for standard applications (not that you go and start modifying your system, but you use custom objects in custom development to protect standard things differently). Just to be clear: I am not saying you must not invent things, but create the authorization concepts using custom objects for custom development only. Don’t force the administrator to try understand the two concepts. In 99% of the cases SAP’s standard concept is much better, more stable, better documented and understood by more developers (in case the “proud author” of this sidetrack concept leaves the company or a project). If your “new concept” works the same as the “old” concept, it doubles the work and effort and all those things without any benefit. If the new concept works differently would you put your hand on a fire that the development department informs the security administrators well enough to ensure the maximum security and understanding?
  5. e) The formed situation can also lead to something even more evil. Instead of authorization objects you are tempted to use evil things like check tables (if a user is there with some setting, it means he/she can do something more or less with the application). This information does not go into any trace and is nearly impossible to trace and debug if you’re not aware of the booby-trap.
  6. Trace your applications (using ST01, SU53 etc.) and compile a list of the AUTHORITY-CHECKs for your security administrator. It will spare you the ping-pong, meetings and certainly one or two tough moments. You should do it regardless of whether you like it or not, it is your job. Information you provide your security administrator with goes to the PFCG roles and also into the transaction SU24 (authorization defaults). It will make you a better person if you familiarize yourself with the transaction, why and how it is used and what is your part of the job in the process.


The "ultimate question" (with answers)

The ultimate question is: “Where do I put the AUTHORITY-CHECK and what type of check do I perform?”


There is no silver bullet answer to the question, but there are some hints and pointers you can follow:


  1. a) “Where do I put the AUTHORITY-CHECK” part of the question has one shortcut you can and should use. Use release APIs (they perform the correct checks). There is no reason to copy SAP standard code and try to invent and hack at the same time. Just go for BAPIs and that’s it. BAPIs normally perform the correct checks and that is what you need – you need to perform the same checks for the same things standard would perform and the checks will be semantically correct, provided by SAP, tested, documented and also “accepted” by all the other customers. In case the BAPI does not perform the correct checks, you should have a pretty good chance to get it fix on OSS. Of course BAPIs are not always available. In that case read further.
  2. b) If you invent something completely new, divorced from SAP standard, the way you build an authorization concept of the application is way beyond the scope of this blog. Which leaves us with custom code that uses SAP standard in a new way (after seeing some hundreds of systems let me assure you very little code is actually something “new”). That means that your code is “doing something like transaction or program XYZ”. Well, that means that your code should perform the same checks. That should answer the “what type of check” part of the “ultimate question”. That’s not that difficult, right? Just run the ST01 trace while testing the application that you’re building on top of (or around) and that will tell you two things: which checks you want to perform and HOW you want to perform them. Note that the ST01 trace is capable of taking you to the part of the code where the check happened. That means that you can double-click the ST01 trace line, jump to the standard code and ideally call that code from your application. If not possible, you have a template you can copy into your application at least.
  3. c) Often you will see that that the code locations you find using the idea from the previous point are central function modules for AUTHORITY-CHECKs on a particular object (or a combination of objects). Use these central functions for checks as much as possible. Often the semantic logic and meaning of the checks and their combinations (and their link to OSS notes and system enhancement options and configuration etc.) are far from being trivial but the interface of these modules is much easier to understand at the same time. You’re welcome to use WHERE-USED list to see how the function is called and mimic that.
  4. d) I have performed my own research on the point c) – how many AUTHORITY-CHECKs are wrapped in the function modules you can easily reuse. Here is the result: I stopped counting when I reached 100 functions in two hours research. Lesson learnt: Some of these checks are MUST-HAVE (-CALL) because the logic is complex and/or allows BADis and customer functions and customizing and enhancement points etc. In many cases the check (or a group of checks) is relatively simple and it would be possible to copy the thing (don’t do it, believe me!). In these cases there are still the two advantages that should win you to call the function instead of copying the check: when SAP changes/ enhances these functions, your code will require no additional maintenance + these functions return translated messages what went wrong (either as a direct exporting parameter or by setting the system variables and an exception). This is very very cool for international environment and even if you don’t care about translations you should go this way to make the end-user experience consistent – same message is returned by a standard transaction as well as you custom code.


I have worked for many customers, performed code reviews and various additional ABAP code + security checks (including organizational problems!!) and if everyone stick to thesimple rules I listed above, world would really become a better place. Try it. Should work for you, worked for me. Don’t forget the most important thing about SCN and blogs -> please provide feedback, add comments, share your stories. I am looking forward to learning something from you as well.

Best regards, sleep well (and be safe and secure), Otto

I am the track lead for the SAP TechEd track called “Security, Identity Management, and Single Sign-On”, in short: “SIS” and I realize that all SAP TechEd attendees have the pain to choose the right session for their particular area of interest.


I really recommend for all of you to pull up your Online Agenda Builder (http://sessioncatalog.sapevents.com/go/agendabuilder.home/?l=58) and logon with your TechEd registration credentials to actually build your agenda. Looking at the session details will give you most of the time a pretty good abstract of each session.


How to get there?


After logging into “My Agenda*”, choose the tab “Sessions” (next to “Content Overview”). Then use the filter capabilities on the left side of this page to actually narrow down the number of sessions to your interest. If you are for example interested in security topics, do the following:


Under “Filters” you should select “Track/Subtrack”, scroll down to the SIS-track and select all four SIS-subtracks. This will already filter down the number of sessions to only 4 pages (from initial 51 pages with the default view of 30 sessions per page). Instead of by Subtrack, you may also filter by “Job Function”. Select “System Administration and Security” to get 17 pages selected out of 51. Keep in mind that almost all sessions are given twice / will appear twce in this list. This will make it easier for you to avoid overlapping times when preparing your schedule.


Of course, I would recommend going to at least session SIS100, the overview session about SAP security functionality (I am the speaker...). In this session, I will point to other sessions that are given at TechEd for you to get deeper insight into certain security related topics. As soon as the PDF-versions of the session material are available on the agenda builder, you may want to download the material in advance for all the sessions of your interest – or you wait to receive the USB drive onsite in Las Vegas with your registration. On the USB drive you will find all session material in PDF format.


Have lots of fun and interesting sessions at #SAPTECHED 2013 !!

Simon Kemp

SQRL - Secure QR Login

Posted by Simon Kemp Oct 13, 2013

I wanted to write a quick post to draw your attention to SQRL - pronounced "Squirrel", short for Secure QR Login.


Steve Gibson from the Gibson Research Corporation (GRC) has come up with SQRL as a potential solution of the ongoing problems associated with using user names and passwords to authenticate to web sites. We have all seen lots of stories in the last couple of years of large web sites being hacked and having their users credentials stolen - some have been encrypted others not, either way it's not a good thing.


If you add to this that many people will use the same password (usually not a strong password either) on different sites and even more commonly people will use the same user id on multiple sites (e.g. your email address) there are lots of issues with good old username/password authentication techniques that need to be improved upon.


In my opinion from what I've seen and heard SQRL seems to go a long way to fixing many of the short comings of existing approaches. From the end users point of view it appears to work almost like magic. By using your smartphone you can scan a QR code from a website and "hey presto" you are automatically logged on.



Screen capture from GRC SQL main page


From a security perspective it is far more secure than traditional username/password techniques and has a number of added advantages too such as out of band authentication (e.g. via your smartphone) and complete anonymity (if you want it).


I am not going to go into the details of SQRL here. Steve does a great job of that on his GRC pages, but I'd encourage you to go and take a look there and then listen to the Security Now podcast where Steve introduces SQRL. Here's the abridged version for the time poor among us:



It took me a few listens and a bit of reading the site to get my head around it, I am no security or crypto expert (it's more of a hobby for me) but I think this is very promising (and pretty cool too). The next step for SQRL is to gain adoption. I want to raise awareness of SQRL  in the SAP security community  here on SCN by writing this post.


I'd love to hear your thoughts in the comments below. What about an SAP ABAP or JAVA server side implementation of SQRL? (DemoJam entry anyone!)


"SQRL - you'd be nuts not to use it!"

With great interest I followed the actual discussion of publishing a SAP hack on sdn by Custodio. In this case, it seems to be the one of "bypassing" the registration code for modifications of SAP owns ABAP prgram sourcecode.

As I mentioned in an earlier blog, I worked for a certain period in time for SAP implementations in the surroundings of national agencies. I think, it would be worthwile to share some of the viewpoints of Do's and Don'ts in the security world in this context.


If you look at "Who is posing threads to IT security in enterprises?" you get a "pyramid".




On the lower side, but nominal the largest groups, you have the script kiddies. This is named after the lowest security thread where you can observe a daily wave of attacks in any environment, shortly after school is out in the afternoon and the "buddies" trying out the latest basic hacker's script that they exchanged on the schoolyard. This is also the name for the occassional hacker, that get's some "exciting tools" from some dark rooms in the internet and try's them out.


This level is no serious thread and is captured by any regular firewall and security measure. The next level is more serious: The level of professional hackers, sometimes associated with organized crime and corporate espionage. The tools are serious and the countermeasure is difficult. They will attack an average system, buit they will fail at serious contermeasures in hardened security environments.


The last level is well present in all newspaper: National agencies, that are utilizing the ultimate tools. Hard to detect, if secret-service-style technology is involved. Feel sure about the latest TPM 2.0 chips in your laptop? Well, Re-Think.


If you look now into the question, who would be talking about his knowledge?


What would you guess? The answer is easy: Only the script kiddies will brag about their stuff in a public way on the Internet. The "claim for fame" is the driver to share, wanted or not, the knowledge with the world. If you look into the blackhat conferences, you will also notice, that even the professionals will only publish the stuff on "skript kiddie" level or the occassional "hot" zero day exploit that act as great topic to make it into the headlines.


On the professional side, everyone who knows the real exploits will use them either to "blackmail" the targets, when he/she is on the blackhat, the evil side, or will try to make money by selling the so called "zero-day" (fresh unknown) exploits back to the original companies, when he/she is a "whitehat hacker", the good one. Usually, the company will pay a prime for every zero-day exploit that is discovered.


Same is valid for the programs and tools for the hacks on this professional level. Tthey will be used either for blackhat hacking (bad guys) or pen tests (good guys) and security hardening. But then you will tell your knowledge only to a very specific audience.


Check out the companies that are doing Penetration tests for SAP? Will they even advertise on Google? I doubt that you will find a lot of them by Google Search. I think, in generally, publishing exploits in public forum is no professional behaviour and is only for the purpose of either "fame for script kids" or teasing about the own knowledge.


If you know the serious hacks, you have no interest in sharing this uncontrolled in public, be it white hat or black hat hacks.


Filter Blog

By author:
By date:
By tag: