Handling Security Threats in Kentico CMS

Karol JarkovskySr. Solution ArchitectKentico Software

http://devnet.kentico.com/Blogs/Karol-Jarkovsky.aspx karolj@kentico.com

Agenda

1. XSS,

2. SQL Injection,

3. Argument Injection,

4. Session Attacks.

NOTE: More information on security threat details and their handling can be found in Kentico CMS Security White Paper available on http://devnet.kentico.com/downloads/Kentico-CMS_Security-White-Paper.pdf - in addition to above also discussses the Code Injection, XPath Injection, XSRF, Directory Traversal, Unvalidated Redirects & Forwards and DoS on Application Layer.

XSSWhat is XSS:

• Cross-site scripting (XSS) is website vulnerability when evil input is rendered as a part of HTML page or such evil input is by rendering used to stole sensitive user data,

• XSS types:

1. Persistent XSS – evil input stored by system,

2. Non-persistent XSS – evil input displayed on the output directly,

3. DOM XSS attacks – type of non-persistent XSS with input usually processed on client-side (no contact with web server),

• Security threats caused by XSS - website inconsistence, user-experience degradation, stealing user auth cookies - MySpace Worm exploit.

XSS

DEMO – XSS I

XSSHow to avoid XSS:

• Whatever text is being displayed by the front-end should be encoded,

• Strings from external sources should be encoded as well,

• Use pre-defined Kentico API methods to handle possible XSS entries:

1. HTMLHelper.HTMLEncode() - to explicitly encode output string,

2. QueryHelper.GetText() - for values coming from URL query string and is rendered to the output directly,

3. ScriptHelper.GetString() – to safely treat strings rendered as dynamic parts of the JavaScript code,

• DO NOT allow rendering any string in JavaScript code directly without proper handling on server side.

XSS

DEMO – XSS II

SQL InjectionWhat is SQL Injection:

• Executing harmful SQL code as a part of system executed query,

• Controlled SQL injections vs. Un-controlled (blind) injections,

• SQL Injection vulnerable website allows attacker execute the same queries as system does,

• Whatever commands are supported on T-SQL level are exposed to the attacker through the SQL injection hole – including xp_cmdshell()

SQL Injection

DEMO – SQL Injection I

SQL InjectionHow to avoid SQL Injection:

• Two options – SQL parameters and escaping single quotes,

• For SELECT, INSERT, UPDATE, DELETE use parameters wherever possible,

• When building WHERE conditions dynamically using input as string data type from external sources always replace apostrophes using ‘.Replace(“ ’ ”, “ ’’ ”),

• Applies also to selection lists and arrays coming in post back – actual values of selection options may be changed through the JavaScript,

• When building WHERE conditions using input different from string data type try to convert it to target data type first – it doesn’t make sense to use replace technique to protect non-string data types,

• Avoid building T-SQL queries on SQL level from input coming from data layer and executing those by exec() statement

SQL Injection

DEMO – SQL Injection II

Argument InjectionWhat is Argument Injection:

• Type of attack based on supplying modified page input parameters used by page logic to display data or perform action with input provided,

• Any page that reads input from URL query string (or any external source, e.g. user’s form input) and process information in any way without any validation mechanism is vulnerable,

• Allows attackers to read sensitive data they’re not allowed to see or perform actions with objects they’re not allowed to perform.

Argument Injection

DEMO – Argument Injection I

Argument InjectionHow to avoid Argument Injection:

• The core of the Argument Injection issue is that data displayed/ modified are identified by parameter passed in the URL – make it difficult to guess identifier for data processed by page – GUIDs secured with hash,

• Use QueryHelper.GetHash() to generate hash for generated URL,• Use QueryHelper.ValidateHash() to validate hash passed in the

URL,

• If possible use context information supplied by Kentico CMSContext class instead of parameters passed in URL – DO NOT need to check hash then,

• Check permissions when manipulating objects identified by parameters - http://devnet.kentico.com/docs/devguide/checking_user_permissions.htm.

Argument Injection

DEMO – Argument Injection II

Session AttacksWhat are Session Attacks:

• Today’s web application solve issues related to fact that HTTP protocol is stateless mostly through by using the session – storage for information on state/ context of user’s interaction with the website,

• User’s session is identified by session ID which is generated on website access and send back and forth with each request - the session ID is key to sensitive user data,

• Most common session related vulnerabilities are:

• Session stealing – achieved through the XSS attacks – stealing ASP.NET_SessionId cookie,

• Session prediction – ASP .NET using 120 bit random number – quite safe,

• Session fixation – tampering attackers session ID to the regular user to gain same state as user.

Session AttacksHow to avoid Session Attacks:

• Do not store any sensitive user related data in the session,

• Protect website from XSS vulnerabilities,

• Manually regenerate session ID once user logs in.

?Questions & Answers

Thank you!