Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Note 1304803 reports can change transp requests? has anyone applied note?

MPGraziano
Participant
0 Kudos

Found the following notes

1304803 Security breach. Certain reports that do not have authorization check can create or change transport requests and change the piece list of a request

and

12988160 - Ability to execute undesired source code in the system using a special call of an RFC module (no further details as to what the 'undesired source code is' has been defined)

Has anyone applied these notes? if so how do you check if the hole exists and then after the note has been applied how does one verify that the security breach has been corrected?

Please advsie

Maria

1 ACCEPTED SOLUTION

Former Member
0 Kudos

>

> Found the following notes

> 1304803 Security breach. Certain reports that do not have authorization check can create or change transport requests and change the piece list of a request

> and

> 12988160 - Ability to execute undesired source code in the system using a special call of an RFC module (no further details as to what the 'undesired source code is' has been defined)

>

> Has anyone applied these notes? if so how do you check if the hole exists and then after the note has been applied how does one verify that the security breach has been corrected?

>

> Please advsie

>

> Maria

Via the corrections of the note, you will often be able to put the puzzle pieces together to be able to "test" whether it is corrected and how... The fact that there are sometimes follow-on notes to such program corrections is evidence of this. Some knowledge and creativity will be required for this.

If you want to be carefull of side affects (or find the guilty ones...) then try where-used-list look-ups on the objects being corrected to see where and how they are being used. Not 100% reliable because of dynamic coding techniques, but a good indicator for auditable development work...

Expressions such as "undesired source code" generally refer to remotely definable but internally executable source code, without appropriate checks in between.

If you cannot test it yourself and SAP releases the note as a "Security Note", then these are generally implementable without SAP standard consequences. If something in the z-custom world is bothered by it, you can normally be sure that you already have the problem "in da house"...

Cheers,

Julius

6 REPLIES 6

Former Member
0 Kudos

>

> Found the following notes

> 1304803 Security breach. Certain reports that do not have authorization check can create or change transport requests and change the piece list of a request

> and

> 12988160 - Ability to execute undesired source code in the system using a special call of an RFC module (no further details as to what the 'undesired source code is' has been defined)

>

> Has anyone applied these notes? if so how do you check if the hole exists and then after the note has been applied how does one verify that the security breach has been corrected?

>

> Please advsie

>

> Maria

Via the corrections of the note, you will often be able to put the puzzle pieces together to be able to "test" whether it is corrected and how... The fact that there are sometimes follow-on notes to such program corrections is evidence of this. Some knowledge and creativity will be required for this.

If you want to be carefull of side affects (or find the guilty ones...) then try where-used-list look-ups on the objects being corrected to see where and how they are being used. Not 100% reliable because of dynamic coding techniques, but a good indicator for auditable development work...

Expressions such as "undesired source code" generally refer to remotely definable but internally executable source code, without appropriate checks in between.

If you cannot test it yourself and SAP releases the note as a "Security Note", then these are generally implementable without SAP standard consequences. If something in the z-custom world is bothered by it, you can normally be sure that you already have the problem "in da house"...

Cheers,

Julius

0 Kudos

Thanks Julius

From your advise I am concluding that it is always best practice to implement the security notes IF they have not been addressed in the SPs Level currently applied.

In fact I received an ASUG newsletter which indicated the same, with regard these two security notes (and two others address in the SP we have already applied)

Correct?

Maria

0 Kudos

I would class these as rouge programs which should never have found their way into the system in the first place and should make very strict security checks if they are to be used at all to make changes.

The coding corrections of these patches do this, or replace them with nasty alerts for having attempted to use them. So there is no valid use case for them in my opinion and from the corrections SAP seems to think the same of their intended use of the system.

I actually used the "bug" in one of the notes to patch itself last year. There were no problems from that.

What you might also want to keep an eye out for are developers who copy these programs and take the checks out again. They should not be able to transport these to production...

Good luck,

Julius

0 Kudos

Great Advise Julius!

I am just delving(sp?) into the Security realm in SAP., and have been trying to find tools that scan for this type of activity , antivirous tools etc.. but I guess some of it comes as pratical experience to look for issues for ... what we term as super programmers!

We could definitly use someone like you on our team over the next year or so, while we bring HCM live and data becomes even more sensitive

Maria

0 Kudos

Human intuition and experience can make a difference, but efficient use of standard SAP tools can cover your risks as well.

One way of doing this is to request that developers scan their code using the SAP Code Inspector (transaction SCI, there are also other SAP tools + even commercially available ones) and attach clean results to their documentation, and then only approve the QA steps if this is fullfilled.

You can even check this in the TMS to mirror the organizational control before attaching the object to a transport request - but this is not standard,

If you already have custom developments (particularly migration tools...) which you have doubts about, then you can also scan these for certain ABAP statements and coding techniques using report RS_ABAP_SOURCE_SCAN.

Suspect statements, such as the ones in these notes which the code inspector would have found, should at least be used in combination with authority-checks and check that they don't expose their source "text" to any external programs or remote callers or the ability to upload it from the PC.

With a small effort you can cover most of the risks quite easily this way.

Cheers,

Julius

0 Kudos

Wow, that's wonderfull Julius....

I definitely value your advice

Maria