Sunday, January 31, 2010

Secure programming in ABAP

In today’s dangerous cyberspace where we experiencing a lot of attracts it is important to consider how SAP applications written in ABAP are protected. Here are introduced some of potential security treats to ABAP program. In addition there are some best practices how we can protect them.

- Password hash attacks - hash value of a password calculated outside SAP and compared to the hash value that is stored in SAP.
- Dynamic SELECT statements – allows to takeover whole DB and possibility to read any table.
- No predefined authority checks - in CALL TRANSACTIONS.
- Executing OS commands – CALL SYSTEM via statement.
- Viruses - E.g. in files uploaded into SAP app. Servers.
- Changes in Master Data.
- Usage of HTTP within BSP, webdynpro apps. – HTTPS must be used.
- Catching passwords transmitted over HTTP by GET method – POST method must be used.
- Manipulating with URL - Attacks on WAS via HTTP protocol.
- Folders in URL - directory traversing possible.
- Cross-site scripting (XSS) – always check user input, there might be malicious code.

Best practices:
- In general protect following components of your SAP ABAP application server: RFC connections, system profile parameters files, Change and Transport system, Table (T000) for Maintaining System Clients,
- Use logging framework (TA SLG0, SLG1, SLG2), change documents functionality (SCDO); logging of customizing objects and tables (TA SCU3) – logging helps to identify problem, auditing, etc.
- Always check Security Audit Log (BC-SEC) – via TA SM20, SM20N.
- Use tool RSECNOTE checks security-relevant notes or HotNews that are entered as related notes in this present note.
- Secure Storage – To securely store data in WAS you this component. See TA SECSTORE.
- Trust Manager - tool used when there is a public-key technology in place with the SAP WAS ABAP server.
- Protect table contents against: export of using transports; access using existing generic tools (TA SE11, SE12, SE16, SE17); external DB access (using SQL tools).
- Disable debugging in Production environment.
- Restrict authorizations for maintaining/executing external OS commands.
- Protect Batch Input sessions – E.g. unauthorized access to files used by batch input, restrict batch input authorizations.
- Secure store and forward mechanism (SSF) as a part of SAP Security Library (SAPSECULIB) – functionality to support digital signatures (ensuring authenticity) and confidentiality of data transmission (encryption).
- Protecting disclosure of SAPconnect RFC User – tool with which ABAP Stack is communicating with external telecommunications services such as FAX, Internet, X.400 and the SAPoffice. It does use a non-dialog RFC user type of CPIC to log on to the external system. Proper authorization profile must be given.
- Preventing or logging list downloading – User can access this functionality via menu option System -> List -> Save as Local file in SAP GUI. Authorization object S_GUI exists to prevent a user from downloading lists.
- Internet Graphics Service (IGS) Security – IGS must be protected by firewall
- While loading data into SAP system (via file upload from front end, FTP server, application server or via electronic data exchange: XML, RFC, IDoc, SAP XI/PI) use SAP Virus Scan Interface (SVI) – SAP provides interface to scan files. This is standard interface called NetWeaver Virus Scan Interface (NW-VSI) available for both Application server stacks: ABAP and JAVA. It does allow 3rd party antivirus software to scan data.
Useful links:


Guillaume Garcia said...

Nice compilation of security-related aspects!
Could you please elaborate on the "Protect table contents" point. Do you refer to the 'Delivery and maintenance' option in SE11, of something else?
Best regards,

sapper said...

Hi Guillaume,

thanks. What I meant within "Protect table contents" are 3 points:

- protection against: export of using transports; transport system should be customized in way that it is not possible to export data from tables via transports request

- protection against: access using existing generic tools (TA SE11, SE12, SE16, SE17); in production environment there should not be access to those TAs for users

- protection against: external DB access (using SQL tools); production DB should be protected by its own tools to avoid running SQL statement on DB engine

But this is story for another blog post :-)


Guillaume Garcia said...

Thank you very much for clarifying!
Best regards,