Tighten your Security and Privacy

© 2012 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.

Tighten your Security and PrivacyLars Krapf | Security Researcher

1


About me

Lars Krapf <[email protected]>

MSc ETH C.S. (Information Security)

Joined Bidule in 1997

Security Researcher (AEM)

2

mailto:[email protected]


Outline

Cross-site scripting (XSS)

– Definition

– XSS in the AEM context

– Prevention

loginAdministrative & Friends

– Risks & Threats

– Identifying Security Issues

– Conclusions

3


Cross-Site Scripting

4


What is Cross-Site scripting?

Web-application security vulnerability

Often underrated

Injection problem

– Same channel used for data and logic

Abuse browser trust

– Circumvent same-origin policy

– HTTPS will not save you

Most web-applications affected

5


Types of Vulnerabilities

Reflected (non-persistent) XSS

– Most common

– Data from client is displayed back directly

– Typically delivered via email or a neutral site

Stored (Persistent) XSS

– Malicious content stored in DB

e.g. Forum post, Profile information, Logfile

– Usually higher impact

DOM based XSS

6


XSS and AEM

Most frequent security bug

– 500+ Issues in JIRA

– Pentest-report contained ~70% XSS bugs

– Large amount of scripts affected

Difficult challenge

– XSS vs SSS

– Customers want HTML paragraph

– DAM

– Can we trust our authors?

7


Attack Vectors

● Request parameters

● URL components

(Path, Selectors, Extension, Suffix, Hash)

● HTTP Headers

● Cookies

● Repository

– Content

– Configuration properties

– Node names / path

(Problem: JCR special characters)

● Log-files

● Filenames


Types of Attackers

Anonymous User

– Usually not able to store content

– Can forge a link and send it to other users / authors (reflected XSS)

– Almost impossible to trace

Authenticated User

– Can store content / profile information

– Largest impact → Critical

Author

– Has read-write access to /content

– Has to be trusted to certain extent

– Good traceability

9


XSS Risks

Manipulate content

Execute scripts

Steal cookies

Clickjacking

Phishing

10


Author vs. Publish

Author

– Attack WEM functionality

– Must be authenticated to access/store content

– Access to Workflows

– Security/Functionality trade-off

Publish

– Large audience

– Weak authentication (or even anonymous)

→ Critical Risk

11


AEM XSS Philosophy

→ Allow all input – Encode all output→ Encode at the very end→ Don't think too much→ Never do it yourself

12


How can we prevent XSS?

Serverside: XSSAPI (AntiSamy), Taglib, JSON-Writer

Clientside: escape(), _g.XSS.getXSSValue()

Cookie Security

Additional measures (e.g. password dialog, hashing)

Browser Security

13


XSSAPI: Methods

14

// Validators public Integer getValidInteger(String integer, int defaultValue);public String getValidDimension(String dimension, String defaultValue);public String getValidHref(String url);

// Encoderspublic String encodeForHTML(String source);public String encodeForHTMLAttr(String source);public String encodeForXML(String source);public String encodeForXMLAttr(String source);public String encodeForJSString(String source);

// Filterspublic String filterHTML(String source);

// JCR based URL mappingpublic XSSAPI getRequestSpecificAPI(SlingHttpServletRequest request);public XSSAPI getResourceResolverSpecificAPI(ResourceResolver resourceResolver);

com.adobe.granite.xssprotection.XSSAPI


AntiSamy configuration

XML configuration file (/libs/cq/xssprotection/config.xml)

Can be overlayed in /apps

Should be adapted to project-specific needs

15


References: Cross-Site Scripting

XSS Cheat Sheet https://wiki.day.com/content/wiki/Dev/Communique/Security/OwaspTopTen/wiki:attachments/xss_cheat_sheet.pdf

OWASP XSS: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

OWASP AntiSamy: https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

XSSAPI JavaDoc: http://dev.day.com/docs/en/cq/current/javadoc/com/adobe/granite/xss/XSSAPI.html

16

https://wiki.day.com/content/wiki/Dev/Communique/Security/OwaspTopTen/wiki:attachments/xss_cheat_sheet.pdf

https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

http://dev.day.com/docs/en/cq/current/javadoc/com/adobe/granite/xss/XSSAPI.html



17



Sling API

– SlingRepository.loginAdministrative

– ResourceResolverFactory.getAdministrativeResourceResolver

– ResourceResolverFactory.getAdministrativeResourceProvider

JCR API

– Session.impersonate

Custom API and Services

– Exposing resources, adaptables or data with admin session

18


Risks & Threats

● General

– Circumventing access control

– Trust boundary violation

– Privilege escalation

● Effects on Read

– Information disclosure

– Privacy violations

– SQL/XPath injections

● Effects on Write

– Content manipulation

– Changing access control

– Creating or modifying executable content

– Access to web console

– File system access

– Access to runtime


Identifying Security Issues

Request Handling

– Admin session used in servlets and scripts

– Usage of API/Services that use admin session

– Mixing different sessions

– Combination with● missing path normalization● missing property validation / restriction● missing node type structure that would help enforcing

constraints

20



Services and API

– API definition forces the use of admin session

– Implementation makes use of admin session● Reading or writing data with admin● Objects bound to admin session● Mixing different sessions

– Caching Issues

– Admin session fields

21



Content Structure

– Data model requires use of admin session

– Data containers such as e.g.● storing backup information● collecting status information● tracking

– Structure created by services without proper ACL setup

22


Conclusions

Request Handling

– Servlets and scripts consistently use the request session:● a single session processes one request● no admin session is used

– Understand the nature of services and API used

– Review access paths of scripts/servlets

– Security risks associated with the input parameters● normalize and verify paths● don't write arbitrary properties / nodes● think about potential exploits

23


Conclusions

Services and API design

– Consider security requirements at an early stage

– Design API/Services such that implementation is possible without admin session

– Use a dedicated user with limited permissions

→ Sling Service Authentication

– Don't mix different sessions

– Don't access caches with different sessions

24


Conclusions

Content Modeling

– Security requirements drive the content structure, such that● managing access control “feels natural”● access control is enforces by the repository and not by the

application– Verify that content has proper permission setup

– Make use of node types to enforce contstraints and limit risk of 'public' write

25


References: loginAdministrative & Friends

Wiki

https://wiki.day.com/content/wiki/Users/anchela/loginAdministrative&Friends.html

CheckList

https://wiki.day.com/content/wiki/Users/anchela/loginAdministrative&Friends/checklist.html

Security FAQ:

https://wiki.day.com/content/wiki/Dev/Communique/Security/SecurityFAQ.html

26

https://wiki.day.com/content/wiki/Users/anchela/loginAdministrative&Friends.html

https://wiki.day.com/content/wiki/Users/anchela/loginAdministrative&Friends/checklist.html

https://wiki.day.com/content/wiki/Dev/Communique/Security/SecurityFAQ.html


Business

Tighten your Security and Privacy