DEFENSE IN DEPTH - Layer Seven Security

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 1Contents11111INTRODUCTIONAPPLICATION SECURITYPLATFORM SECURITYPROGRAM SECURITYCLIENT SECURITY236810

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 2IntroductionThe protection of SAP systems against unauthorized access andmanipulation demands security measures at multiple levels.According to SAP, this includes measures covering landscapearchitectures, operating systems and databases, as well as SAPtechnologies, applications and authorizations. 1This white paper outlines an integrated strategy for securing SAPsystems based on the principles of Defense in Depth. The strategyis designed to protect the confidentiality, integrity and availabilityof SAP programs and data through countermeasures appliedwithin each interconnected layer in SAP environments.These measures are applied across four distinct areas in SAPsystems: Application, Platform, Program and Client. The secureconfiguration and management of these areas lowers the risk ofsystem intrusion, protects the confidentiality of business informationand ensures the authenticity of users. Each area is reviewedin detail in the white paper.NETWORK SECURITYDefense in Depth is the only practical strategy for informationassurance in highly integrated SAP landscapes susceptible to avariety of attacks through numerous access points. The strategyrequires the implementation of multiple obstacles betweenadversaries and their targets. This is designed to lower the risk ofa successful attack, contain the impact of a network intrusion andimprove the likelihood of detection.The deployment of nested firewalls coupled with intrusionprevention represents the first line of defense and is an importantcomponent of network-level security. However, organizationsshould not rely exclusively upon such technologies. Both firewallsand intrusion prevention systems can be bypassed by skilledattackers, evidenced by recent well-publicized data breaches.Firewalls are especially vulnerable. The most common form ofnetwork firewalls, stateful packet filters, do not analyze applicationpayloads. Consequently, they are ineffective against SAPattacks. Application Gateways provide a greater level of protectionand are therefore recommended for high-integrity environments.Network controls should be balanced with appropriate policiesand procedures, physical controls and monitoring throughSecurity Information and Event Management (SIEM) solutions.They should also be supported by technical measures such asencrypted communications, hardened servers, robust programsand effective access controls, designed to protect informationresources even if a network is breached.MONITORINGAPPLICATIONCustomizationAccess GovernancePLATFORMNetWeaver ASOperating SystemDatabasePROGRAMSecure Soſtware DevelopmentDynamic and Static Code AnalysisTransport ManagementCLIENTSAP GUIWeb BrowserDesktop HardeningPHYSICAL SECURITYTable 1.1: Defense in Depth for SAP SystemsPOLICIES & PROCEDURES1 Secure Configuration of SAP NetWeaver Application Server Using ABAP, SAP AG, 2012 LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 412345678910Single and Unique User AccountsLeast PrivilegeRoles Based Access Control (RBAC)Separation of Duties.Control BenchmarksDocumentationApprovalMaintenanceLoggingMonitoringROLES BASED ACCESS CONTROL (RBAC)Authorizations should not be assigned directly to users. Rather,permissions should be incorporated into roles which are thenprovided to users. This creates transparent access control modelsand enables efficient user provisioning. SAP roles should closelyalign to the tasks performed by role members in organizations.Indirect role assignment through Organizational Management (OM)in HCM can be used to align SAP roles to actual roles and responsibilitiesand automate user provisioning.SEPARATION OF DUTIESSAP landscapes contain an array of diverse and integratedapplications. In most cases, user management is performedcentrally within such landscapes and users with broad authorizationsare able to perform wide-ranging, cross-application functionsthat in combination may present a risk to organizations. Forexample, users granted authorizations for both invoice entry andasset disposal through transactions such as FB60, FB65 and F-92are able to process fraudulent invoices for fictitious asset acquisitionsand eliminate the risk of detection through asset sales orretirement.Table 2.1: The Principles of SAP Access GovernanceSINGLE AND UNIQUE USER ACCOUNTSUsers should not be assigned multiple accounts in the identicalsystem. This can lead to the accumulation of excessive orconflicting authorizations without detection. Also, users should beassigned unique, personal accounts for system access. Shared orgeneric accounts increase the risk of unauthorized access throughpassword sharing. Actions performed by generic users are alsodifficult to trace to specific individuals which impacts logging andmonitoring.LEAST PRIVILEGEUsers should be granted the minimal authorizations required toperform their tasks. Furthermore, authorizations should only begranted for the required organizational groups. Broad businessroles require greater authorizations and therefore increase the riskthat users may be assigned conflicting privileges. This can beaddressed through approval, monitoring and other compensatingcontrols when business roles cannot be redesigned.Risks can also occur within an application area. For instance,creating and maintaining employee records using authorizationssuch as PA30 and PA40 can lead to a risk when combined with thepermission to run payroll processing programs through theauthorization object P_ABAP.Hence, the identification and segregation of conflicting authorizationsis a vital component of access management in SAP systems.The separation of duties implements preventative internal controlsthat significantly reduce the opportunity for fraud and error. Itshould be applied at both the profile and cross-profile level andinclude custom-developed authorization objects, profiles, roles andtransactions.CONTROL BENCHMARKSThe assignment of sensitive authorization and the separation ofduties should be conducted in accordance with generally-acceptedbenchmarks for SAP systems. Deviations from the standards insuch benchmarks should be documented and supported withadequate compensating controls. Reliable sources for controlstandards include SAP Best Practices and rule-sets embedded inSAP GRC and leading third party authorization managementsolutions such as CSI Authorization Auditor. Matrices available inthe SAP Developer Network may be used as a reference butshould not be considered a benchmark for control standards.LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 5DOCUMENTATIONThe SAP authorization structure should be maintained indocumented form as a reference for internal and external stakeholders.This should include information related to profiles, singleand composite roles, user groups, administrators, authorizationand transaction assignments, segregation of duties and proceduresfor profile changes and access provisioning.APPROVALAn effective SAP access management framework should includerequirements for approvals at multiple levels. The content ofauthorization profiles in SAP roles should be approved andcontrolled by designated role owners representing business andtechnical areas. The responsibility for managing access assignmentsand segregation of duties across roles should be assigned tooverall system owners since role owners generally only havevisibility to risks in their specific domain. Also, every assignment ofauthorizations to users must be pre-approved. In most cases,approval should be explicit. However, implicit approval is acceptablewhen provisioning access through indirect assignment using OM.MONITORINGSAP roles, profiles and authorizations should be periodicallyreviewed and validated by business owners. Any errors in permissionsand assignments should be removed within a reasonableperiod. Inactive and locked users should be identified and investigated.Monitoring should also include a regular review of relevantapplication-level settings in the IMG and should be augmentedwith independent assessments performed by internal or externalauditors or consultants.MAINTENANCESecurity Notes and Upgrades are issued by SAP to patch missing orincomplete authorization checks in standard programs. Notesshould be applied within 30 days of the release date. Upgradesshould be performed through procedures in transaction SU25. Thisprovides a comparison of existing check indicators against SAPdefaults. The alternative procedure involves assigning theSAP_NEW profile included in each upgrade to all users. Thisapproach carries significant risks and could potentially violate theprinciples of least privilege and the separation of duties. Theupgrade procedure is considerably easier and less time consumingin environments where SAP template roles are leveraged toprovision user access, rather than custom-developed roles.Templates cover approximately 80 percent of the roles required forstandard functions and processes.LOGGINGSAP systems should be configured to provide an audit trail ofsignificant user actions. This includes the creation, change ordeletion of documents and other objects. It also includes userprovisioning and actions related to the administration of authorizationprofiles and roles. Actions should be traceable to specific usersand include date and time stamps. Logs should be retained for asufficient period, usually 12 months. Regular archiving of logs willminimize the size of log files and any impact on system performance.LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 6Platform SecurityThe technical components of SAP environments are NetWeaverApplication Servers (AS) and underlying database and operatingsystems which together provide the platform for SAP applications.Vulnerabilities at the platform level can enable internal andexternal attackers to bypass application-level controls. Therefore,approaches to security that focus primarily upon applications mayprovide a false sense of security if architectural and configurationflaws are not addressed at the platform level.The NetWeaver AS is the technical foundation of the entire SAPsoſtware stack. It provides the runtime environment for SAPapplications and includes work processes for ABAP and Javaprograms, gateways and modules for managing RFC, Web-basedand other forms of communication protocols, tools to manageuser roles, profiles and authorizations, and utilities that controlcertain database and operating system functions. The secureconfiguration and management of the NetWeaver AS is therefore avital component of an integrated SAP security strategy. Applicationservers must be secured against common threats and vulnerabilitiesthat can lead to fraud, espionage and sabotage. This shouldinclude the measures outlined below.NETWORK FILTERINGUnnecessary network ports and services should be disabled. Inmost cases, this means blocking all connections between end usernetworks and ABAP systems other than those required by theDispatcher (port 32NN), Gateway (33NN), Message Server (36NN)and HTTPS (443NN). NN is a placeholder for SAP instancenumbers. Administrative access should only be allowed throughsecure protocols such as SSH and restricted to dedicated subnetsor workstations through properly configured firewall rulesSAP GUIInstallation of the latest version of SAP GUI, ideally 7.20 with activeand properly configured security rules. Scripting and input historyshould be deactivated or otherwise controlled. The section relatedto client security contains further information on securitymeasures for SAP GUI.PASSWORD MANAGEMENTImplementation of strong password policies, access controls forpassword hashes in tables and activation of the latest hashingalgorithms. Default passwords should be changed for standardusers and password hashing mechanisms should be upgraded tothe most current applicable versions. Wherever possible,downward-compatible hashes should be removed from databases.NETWORK ENCRYPTIONSAP client and server communication traffic is not cryptographicallyauthenticated or encrypted. Therefore, data transmitted withinSAP networks can be intercepted and modified through Man-In-The-Middle attacks. Secure Network Communication (SNC) shouldbe used for mutual authentication and strong encryption. This canbe performed natively if both servers and clients run on Windows.Non-SAP soſtware is required to secure connections betweenheterogeneous environments such as AIX to Windows.WEB SERVICESSAP functions and programs can be Web-Enabled. This ismanaged through the Internet Communication Framework (ICF),accessible through transaction SICF. Many of the default servicesin ICF could enable unauthorized and malicious access to SAPsystems and resources, oſten without authentication. Hence,services that are not required for business scenarios should bedeactivated. This should include SAP/RFC, Echo, XRFC, WEBRFC,IDOC and IDOC_XML.REMOTE FUNCTION CALLS (RFC)RFC is the most widely used communication protocol in SAPlandscapes and supports integration between SAP systems andenvironments. Trust relationships should not be established inRFC connections between systems with differing security classifications.Furthermore, hardcoded user credentials should beavoided in RFC destinations. Connections with excessive privilegesare a particularly high risk. This includes connections configuredwith SAP_ALL privileges, regardless of whether the user type isset to communication or system rather than dialog.SAP GATEWAYThe Gateway is used to manage RFC communications whichsupport SAP interfaces such as BAPI, ALE and IDoc. AccessControl Lists (ACL) should be created to prevent the registration ofrogue or malicious RFC servers which can lead to the interruptionof SAP services and compromise data during transit. Furthermore,Gateway logging should be enabled and remote access disabled.4LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 7MESSAGE SERVERThe Message Server is used primarily as a load balancer for SAPnetwork communications. Similar to the Gateway, the MessageServer has no default ACL. Therefore, it is susceptible to theidentical vulnerabilities. Network access to the Message Serverport should be filtered through a firewall and an ACL should beestablished for all required interfaces.PATCH MANAGEMENTSAP periodically releases patches for programming and otherflaws through Security Notes, available at the Service MarketPlace. Standard reports such as RSECNOTE should be regularlyreviewed to identify missing Security Notes. Alternatively, the SAPSolution Manager should be configured to manage Notes andsupport the change process for registered components. Noteswith a severity rating of 1 require immediate attention. Notes witha severity rating of 2, 3 or 4 should be targeted for implementationwithin 30 days of release.LOGGING AND MONITORINGThe Security Audit Log should be enabled to record specificsecurity events such as changes to user master records, logonattempts using SAP* and successful and unsuccessful logons.These events are recorded in local files stored on applicationservers. Static and dynamic filters should be configured for specificclients, users and classes to ensure that critical events areconfigured and logged.also be used as a benchmark. However, both vendor-specificrecommendations and benchmarks should be applied carefullyand selectively since they may conflict with SAP requirements.12345678910Network FilteringSAP GUIPassword ManagementNetwork EncryptionWeb ServicesRemote Function Calls (RFC)SAP GatewayMessage ServerPatch ManagementLogging and MonitoringTable 3.1: NetWeaver AS SecuritySAP services such as EarlyWatch (EWA) and the Computing CenterManagement System (CCMS) should be used to monitor certainsecurity events and parameters. However, they do not provide thesame coverage as professional-grade vulnerability assessmentsolutions engineered specifically for SAP systems.The other components of SAP platforms include database serversand operating systems. Such components should be configured inaccordance with SAP recommendations covering areas such asestablishing authentication schemes, protecting system and loginusers, changing default passwords, domain-level settings andmanaging access privileges for data tables, files, directories andother resources. However, SAP recommendations are not intendedto be exhaustive. For example, SAP has no specific recommendationfor database encryption. Therefore, databases and operatingsystems should also be secured in line with the more comprehensiverecommendations issued by soſtware vendors. Securityguidance issued by organizations such as CIS, NIST or SANS mayLAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 8Program SecurityThe third component of an integrated SAP security strategy is thedevelopment of secure custom programs, free of code-levelvulnerabilities.SAP systems are designed to perform thousands of distinctfunctions ranging from adding a vendor to a list of approvedsuppliers, performing a transport to implement a change in aspecific system, and encrypting/decrypting traffic between serversor clients. These functions are performed by programs stored in thedatabase table known as REPOSRC that are called when requestedby work processes in the NetWeaver AS.SAP programs are developed using two distinct programminglanguages: Advanced Business Application Programming (ABAP)and Java. Both are vulnerable to coding errors that could exposeSAP programs to exploits such as code, OS and SQL injection,cross-site scripting, cross-site request forgery, buffer overflow,directory traversal and denial of service. SAP programs are alsosusceptible to missing or broken authority-checks that could leadto the unauthorized execution of programs. Finally, programs cancontain backdoors through hardcoded credentials that bypassregular authentication and authorization controls, as well asmalware known as rootkits that provide attackers with remote,privileged access to system functions and resources. Table 4.1 liststhe 25 Most Dangerous Soſtware Errors identified by the CommonWeaknesses Enumeration (CWE), co-sponsored by the Office ofCybersecurity and Communications at the U.S Department ofHomeland Security. ABAP and Java programs are vulnerable to70% of the vulnerabilities in the list and are highlighted in red.1Improper Neutralization of Special Elements used inan SQL Command ('SQL Injection')14Download of Code Without Integrity Check2Improper Neutralization of Special Elements used inan OS Command ('OS Command Injection')15Incorrect Authorization3Buffer Copy without Checking Size of Input ('ClassicBuffer Overflow')16Inclusion of Functionality from Untrusted ControlSphere4Improper Neutralization of Input During Web PageGeneration ('Cross-site Scripting')17Incorrect Permission Assignment for CriticalResource5Missing Authentication for Critical Function18Use of Potentially Dangerous Function6Missing Authorization19Use of a Broken or Risky Cryptographic Algorithm7Use of Hard-coded Credentials20Incorrect Calculation of Buffer Size8Missing Encryption of Sensitive Data21Improper Restriction of Excessive AuthenticationAttempts9Unrestricted Upload of File with Dangerous Type22URL Redirection to Untrusted Site ('Open Redirect')10Reliance on Untrusted Inputs in a Security Decision23Uncontrolled Format String11Execution with Unnecessary Privileges24Integer Overflow or Wraparound12Cross-Site Request Forgery (CSRF)25Use of a One-Way Hash without a Salt13Improper Limitation of a Pathname to a RestrictedDirectory ('Path Traversal')Table 4.1: CWE Top 25 Most Dangerous Soſtware Errors(Source: CWE/MITRE, 2012)LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY9SAP performs a rigorous code review for all standard or deliveredprograms prior to release and regularly issues Security Notes topatch vulnerabilities detected aſter release. Custom programs arerarely subject to the same level of scrutiny. Programs developed byin-house or off-shore developers to meet the needs of customersnot met by standard SAP functionality are oſten laden with vulnerabilitiesthat, when exploited, undermine the integrity of entire SAPlandscapes. Such landscapes are only as strong as their weakestpoint. A robust application layer fortified with properly configuredplatforms can still be breached through vulnerabilities at theprogram level.SAP does not assume responsibility or liability for losses arisingfrom the exploitation of vulnerabilities in custom code. Customersare expected to develop and apply appropriate soſtware developmentprocedures to manage such risks. Procedures should includerequirements for soſtware integrity and security and should notfocus exclusively on measures such as functionality and performance.Specific examples include the use of open rather thannative SQL, avoiding arbitrary input for dynamic SQL statements,encoding user input before output, removing hardcoded users,secure construction of SELECT statements, and input validationthrough existence and length checks, canonicalization, type checks,range checks and white or black list filters.Developing secure custom programs is a formidable challenge formany SAP customers. ABAP and Java programmers are generallyunfamiliar with secure programming techniques. Furthermore,manual code reviews can increase resource requirements andtimeframes during development and testing. Standard SAP toolssuch as Code Inspector can be used to perform static checks andtests for development objects. Code Inspector is accessed throughthe ABAP Workbench or directly through transaction SCI. Thedefault check variant includes some checks for security risks.Errors, warnings and messages generated by the Code Inspectorshould be investigated and resolved before the release of transports.Code Inspector does not match the performance of soſtware suchas CodeProfiler designed to detect a wider array of vulnerabilitiesin SAP programs. CodeProfiler is used by SAP to perform qualityassurance for standard programs. It is tuned to detect andauto-correct suspicious statements in ABAP programs andintegrates directly with the SAP Transport Management System toprevent the deployment of malicious code. It scans an average of2.24M lines of ABAP code per project and detects an average of5,065 critical errors, of which over 2,400 are considered criticalsecurity flaws. CodeProfiler is SAP-certified for integration withSAP NetWeaver.LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 10Client SecurityThe fourth component of an integrated SAP security strategy isclient-level security. Clients are oſten a target for attack since theycan provide an unguarded corridor to SAP applications andplatforms. There are two primary clients supporting a variety ofuser interfaces. The first is SAP GUI. The desktop variant of SAPGUI is a thick client installed on Windows, Apple or UNIX workstations.It is the most widely used method of accessing SAP applicationservers and is the rendering engine for the desktop version ofthe recently introduced NetWeaver Business Client (NWBC).There are several precautions required for the secure use of SAPGUI. This includes disabling the scripting API which can be abusedto execute transactions and processes in the background. Anotherreason for disabling scripting is that scripts oſten storeunencrypted logon data in local files. Credentials can be read andused by attackers if a workstation is compromised. Automaticsecurity warnings should be enabled for users that require the useof SAP GUI scripting. This will alert users when a script is executed.Security rules should be configured to prevent the ability ofattackers to exploit SAP shortcut commands. Similar to scripting,such commands can enable attackers to interact with SAP serverswithout the knowledge of the user.Input history should be disabled. Although SAP GUI does not storedata entered in password fields, it can be configured to store datakeyed by users in other fields. This may include sensitive customer,financial or other information. The data is stored in local Accessdatabases.The communication path between SAP GUI and application serversis not encrypted by default. Therefore, data transfers betweenclients and servers are in clear text. SNC (Secure NetworkCommunication) should be used to secure the path. This is asoſtware component that applies symmetric encryption algorithmsfor DIAG and RFC protocols through the GSS-API V2 interface toexternal security products. SAP Note 1643878 provides instructionsfor enabling SNC in SAP GUI 7.20, Patch Level 7 and higher.Earlier versions of SAP GUI are vulnerable to buffer overflowexploits that can lead to the injection of malicious code designed tocorrupt SAP programs and processes. Solutions include eitherapplying the relevant patches released by SAP or upgrading SAPGUI to the latest available version. Program files in SAP GUI 7.20and higher are digitally signed by SAP. This protects sensitive filesagainst unauthorized modification.Later versions of SAP GUI also feature a security module toprotect the local environments of users. The module leveragesrules to control potentially dangerous or malicious actionstriggered by back-end systems related to specific files, extensions,directories, registry keys and values, ActiveX controls andcommand lines. Rules should be configured and applied centrallybut can vary by user or system groups. They can also be contextdependant.The rules are employed when the module is configuredin 'Customized' mode and are applied in sequential order. Therefore,higher order rules take precedence over lower rules. Thedefault response for actions not defined in the rules should be setto 'Ask' or 'Deny' rather than 'Allow'SAP GUI for HTML provides a thin alternative to thick desktopclients. This provides a browser-based platform for SAP access.Browsers also support the presentation layer for NWBC for HTML,the CRM WebClient UI and Java applications such as the EnterprisePortal. Supported browsers include specific versions of IE, Firefox,Safari and Chrome. However, certain browsers are not supportedby some SAP applications.Since browsers provide varying levels of protection, the ability toaccess SAP resources should be restricted to specific types. Thiscan be performed by deploying standardized desktop images thatinclude only approved browsers, supported by group policy rulesthat restrict end user privileges to install executable programs.Controls can also be implemented at the SAP level. For example,4LAYER SEVEN SECURITY © 2013

DEFENSE IN DEPTH AN INTEGRATED STRATEGY FOR SAP SECURITY 11the Enterprise Portal can support browser-checking to block connectionattempts from unsupported browsers.Microsoſt Internet Explorer offers the greatest protection for SAPaccess. The ability to configure trusted zones provides a seamlessuser experience while safeguarding against malicious applets, scriptsand downloadable content from untrusted sites. The use of Firefoxshould be avoided, wherever possible. Weaknesses in the existingarchitecture of the browser can enable vulnerabilities in add-ons to goundetected by anti-virus solutions.Web browser security should be supported with Web content filtering,anti-virus and anti-spyware, two-factor authentication for remoteaccess, as well as regular patching of browsers and operatingsystems. Personal firewalls can be enabled for added protection,including stateful inspection firewalls available in some Windowsoperating systems. However, firewall rules should be thoroughlytested to ensure they do not inadvertently block access to SAP andother business applications. Operating systems should be hardened inline with security recommendations issued by vendors or in accordancewith generally-accepted configuration benchmarks. ForWindows systems, hardening should include enabling file protection,strong password policies, account lockouts, roles-based access basedon least privilege, and disabling services such as FTP, Messenger,Remote Desktop Sharing and Telnet.LAYER SEVEN SECURITYLayer Seven Security specialize in SAP security. The companyserves customers worldwide to protect SAP systems againstinternal and external threats and comply with industry andstatutory reporting requirements. It fuses technical expertise withbusiness acumen to deliver unparalleled implementation,consulting & audit services targeted at managing risks in contemporarySAP systems.Layer Seven Security employs a distinctive approach to SAP riskmanagement that examines and manages vulnerabilities at theplatform, application, program and client level. Through partnershipswith leading soſtware developers, the company is able todevelop SAP systems with defense in depth and performintegrated security assessments that improve the quality andlower the cost of SAP audits. Layer Seven Security leverageleading SAP-certified solutions to provide comprehensive andrapid results covering risks in every component of SAPlandscapes.www.layersevensecurity.comBasic authentication should be avoided for HTTP connections since itdoes not sufficiently protect user credentials during transport betweenclients and SAP servers. Also, it is susceptible to phishing attackssince servers are not authenticated. Phishing involves the redirectionof users to malicious servers with logon screens that appear identicalto those of legitimate SAP servers. User credentials entered intomalicious servers can be used to compromise SAP systems. As aresult, SAP strongly recommends the use of SSL/ HTTPS to securebasic authentication. This encrypts client-server communication andauthenticates SAP servers. SSL requires the configuration of digitalcertificates which can be obtained from SAP Trust Center Services.SSL also protects SAP logon tickets used for single sign-on. Theseare authentication tickets stored as non-persistent cookies inbrowsers. However, this does not include safeguards againstcross-site scripting attacks that attempt to read cookies through theexecution of client-side scripts. This requires alternativecounter-measures including the configuration of cookies asHTTP-only. The parameter setting ume.logon.httponlycookie=true willprevent malicious attempts to read SAP logon tickets.LAYER SEVEN SECURITY © 2013