Handling Security Threats in Kentico CMS

1. Handling Security Threats in Kentico CMS Karol Jarkovsky Sr. Solution Architect Kentico Software http://devnet.kentico.com/Blogs/Karol-Jarkovsky.aspx karolj@kentico.com

2. Agenda • XSS, • SQL Injection, • Argument Injection, • 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.

3. 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: • Persistent XSS – evil input stored by system, • Non-persistent XSS – evil input displayed on the output directly, • 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.

4. XSS DEMO – XSS I

5. 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: • HTMLHelper.HTMLEncode() - to explicitly encode output string, • QueryHelper.GetText() - for values coming from URL query string and is rendered to the output directly, • 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.

6. XSS DEMO – XSS II

7. 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()

8. SQL Injection DEMO – SQL Injection I

9. SQL Injection • How to avoid SQL Injection: • Two options – SQL parameters and escaping single quotes, • For SELECT, INSERT, UPDATE, DELETEuse 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 WHEREconditions 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

10. SQL Injection DEMO – SQL Injection II

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

12. Argument Injection DEMO – Argument Injection I

13. 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 CMSContextclass 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.

14. Argument Injection DEMO – Argument Injection II

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

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

17. Questions & Answers ?

18. Thank you!