Handling Security Threats in Kentico CMS Karol Jarkovsky

Handling Security Threats in Kentico CMS Karol Jarkovsky Sr. Solution Architect Kentico 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 Do. S on Application Layer.

XSS What 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 - My. Space Worm exploit.

XSS DEMO – XSS I

XSS How 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. Query. Helper. Get. Text() - for values coming from URL query string and is rendered to the output directly, 3. Script. Helper. Get. String() – to safely treat strings rendered as dynamic parts of the Java. Script code, • DO NOT allow rendering any string in Java. Script code directly without proper handling on server side.

XSS DEMO – XSS II

SQL Injection What 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 Injection How 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 Java. Script, • 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 Injection What 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 Injection How 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 Query. Helper. Get. Hash() to generate hash for generated URL, Use Query. Helper. Validate. Hash() 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 Attacks What 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_Session. Id 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 Attacks How 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!