!! Warning !! I may be endangering your system security
For quite a few year now, there has been some functionality built into the SE16N table viewing transaction. It allows those with very high access authorizations to make changes to transportable tables without creating a transport, and even to do so in productive systems.
It's completely against all the rules of careful structured regulated process. Which is fine by me 😉 Joking aside, sometimes it is really useful for making a quick and dirty fix to some configuration/table data that just can't be done otherwise. The number of times I have fixed data that has been messed up by code errors using this tool is beyond me to count. (Doesn't say great things about my code does it!)
If the title of this blog, and the descriptions I've given haven't been enough to tell you what I'm talking about, I'm not going to elaborate any further - sorry - but I'm sure I'm already going to be accused of further adding to the problem by writing this blog. Given that there are various threads out there e.g. the Edit function removed from SE16N transaction, reports and interface FM I'm not really opening a can of worms (or at least I hope not.)
Well SAP (or at least one of their customers) picked up on this and now this incredibly useful functionality has gone away. This is the gist of the note 1420281 which comes in a range of recent(ish) (well the note was released in March, that's kinda recent isn't it?) support packages. Many of the customers I'm working at are now at these support pack levels and it is becoming more and more frustrating.
Security through obscurity
If you look up the Wikipedia entry for Security through obscurity you'll find (probably - - hey this is Wikipedia - it may have changed by the time you read this 😉 :
"Security through (or by) obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them."
This is exactly what SAP have done in this recent note.
Come again - what did you say?
Let me take a second to explain. In the code for SE16N there are various checks against the user's security authorization if they ever try to directly maintain a table. Which I think is perfectly fair. The developers of the solution decided that the most important authorisation to check was the one that allowed you to make changes to values within debug. Arguably if you have access to this (debug change) functionality, you can do anything in the system if you have enough time. I can testify that I've used this occasionally to give myself SAP_ALL authorization profile when the system admin has been away sick and we needed to get some work done. Those clever people who wrote the SE16N code decided that if you had those auths, well they weren't going to be able to stop you - so why not make your life easier! And that's what they did.
If you look at the code changes in the note all that has been changed is the simple way to alter a couple of global variables in the function group. Which you can easily do using debug.
Applying this note does NOTHING to improve the security of your system from someone with the most basic of SAP knowledge and a search engine.
I find it incredulous that SAP have been pushed (as this is all I can see that has happened) into making a ridiculously simple code change that does very little to actually improve the security of the system. The real issue is not that the SAP code allowed users this functionality, but that security is so lax in many environments that this is a problem in the first place.
Are you happy now Auditors?
Fortunately for me, there are other transactions with almost exactly the same functionality, that haven't been "patched" - so I'm not going to have to resort to the debugger the next time I'm faced with a data f***-up in production. But you have to ask - "Why, SAP did you release this patch?" Is it not clearly the fault of those in charge of managing system security for giving users far too much access? This is clearly just lip service to the concerns of some SAP customers who haven't got their house in order. And now my job, working at those SAP customers who do take security seriously, has gotten just a little bit more difficult.
OK - rant over. Time to be happy and smiley and get back to doing some Web Dynpro ABAP and building some more REST services (bit of JSON mixed with Atom Pub anyone 😉 Thanks for bearing with me!
A Final Plea
However Please - if you do know of other ways to circumvent these "attempts" to make SAP more secure - please don't post them. It's because people who really haven't got a clue are messing with live systems that these sort of ridiculous changes occur. If and when I have to do production support - I really don't need my life made any harder 🙂 Thanks!
Disclaimer: you shouldn't listen to anything I say. It's likely to be wrong, misleading, confusing and unrepresentative, and in no way reflects the opinions of my employer or any sane person. 😉
13 Comments
