Handling Security Threats in Kentico CMS Karol Jarkovsky Sr. Solution Architect Kentico Software

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 Paper.pdf - in addition to above also discussses the Code Injection, XPath Injection, XSRF, Directory Traversal, Unvalidated Redirects & Forwards and DoS on Application Layer. Paper.pdf

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 - MySpace 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.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 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 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 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 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 -

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_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 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!