Tighten your Security and Privacy

© 2012 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.
Tighten your Security and Privacy
Lars Krapf | Security Researcher

About me
 Lars Krapf <lkrapf@adobe.com>
 MSc ETH C.S. (Information Security)
 Joined Bidule in 1997
 Security Researcher (AEM)

Outline
 Cross-site scripting (XSS)
– Definition
– XSS in the AEM context
– Prevention
 loginAdministrative & Friends
– Risks & Threats
– Identifying Security Issues
– Conclusions

Cross-Site Scripting

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

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

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?

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

XSS Risks
 Manipulate content
 Execute scripts
 Steal cookies
 Clickjacking
 Phishing

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

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

XSSAPI: Methods
14
// Validators
public Integer getValidInteger(String integer, int defaultValue);
public String getValidDimension(String dimension, String defaultValue);
public String getValidHref(String url);
// Encoders
public String encodeForHTML(String source);
public String encodeForHTMLAttr(String source);
public String encodeForXML(String source);
public String encodeForXMLAttr(String source);
public String encodeForJSString(String source);
// Filters
public String filterHTML(String source);
// JCR based URL mapping
public 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

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

loginAdministrative & Friends

loginAdministrative & Friends
 Sling API
– SlingRepository.loginAdministrative
– ResourceResolverFactory.getAdministrativeResourceResolver
– ResourceResolverFactory.getAdministrativeResourceProvider
 JCR API
– Session.impersonate
 Custom API and Services
– Exposing resources, adaptables or data with admin session

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

 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

 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

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

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

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

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

Tighten your Security and Privacy

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Tighten your Security and Privacy

Similar to Tighten your Security and Privacy (20)

More from connectwebex

More from connectwebex (19)

Recently uploaded

Recently uploaded (20)

Tighten your Security and Privacy