Web Security: Understanding Cookies, Same Origin Policy, and Cross-Site Scripting Attacks, Slides of Javascript programming

Download Web Security: Understanding Cookies, Same Origin Policy, and Cross-Site Scripting Attacks and more Slides Javascript programming in PDF only on Docsity! Information Security Web Security docsity.com Readings for This Lecture • Wikipedia • HTTP Cookie • Same Origin Policy • Cross Site Scripting • Cross Site Request Forgery docsity.com Web Security Issues • Secure communications between client & server • HTTPS (HTTP over SSL) • User authentication & session management • Cookies & other methods • Active contents from different websites • Protecting resources maintained by browsers • Web application security • Web site authentication (e.g., anti-phishing) • Privacy concerns docsity.com HTTP: HyperText Transfer Protocol • Browser sends HTTP requests to the server • Methods: GET, POST, HEAD, … • GET: to retrieve a resource (html, image, script, css,…) • POST: to submit a form (login, register, …) • HEAD • Server replies with a HTTP response • Stateless request/response protocol • Each request is independent of previous requests • Statelessness has a significant impact on design and implementation of applications docsity.com Use Cookies to Store State Info • Cookies • A cookie is a name/value pair created by a website to store information on your computer Browser Server Enters form data Response + cookies Browser Server Request + cookies Returns data Http is stateless protocol; cookies add state docsity.com Web Authentication via Cookies • HTTP is stateless • How does the server recognize a user who has signed in? • Servers can use cookies to store state on client • After client successfully authenticates, server computes an authenticator and gives it to browser in a cookie • Client cannot forge authenticator on his own (session id) • With each request, browser presents the cookie • Server verifies the authenticator docsity.com A Typical Session with Cookies client server POST /login.cgi Set-Cookie:authenticator GET /restricted.html Cookie:authenticator Restricted content Verify that this client is authorized Check validity of authenticator Authenticators must be unforgeable and tamper-proof (malicious clients shouldn’t be able to modify an existing authenticator) How to design it? docsity.com Cross Site Scripting docsity.com Scripts are Powerful • Client-side scripting is powerful and flexible, and can access the following resources • Local files on the client-side host • read / write local files • Webpage resources maintained by the browser • Cookies • Domain Object Model (DOM) objects • steal private information • control what users see • impersonate the user docsity.com Browser as an Operating System • Web users visit multiple websites simultaneously • A browser serves web pages (which may contain programs) from different web domains • i.e., a browser runs programs provided by mutually untrusted entities • Running code one does not know/trust is dangerous • A browser also maintains resources created/updated by web domains • Browser must confine (sandbox) these scripts so that they cannot access arbitrary local resources • Browser must have a security policy to manage/protect browser-maintained resources and to provide separation among mutually untrusted scripts docsity.com Same Origin Policy • The basic security model enforced in the browser • SoP isolates the scripts and resources downloaded from different origins • E.g., evil.org scripts cannot access bank.com resources • Use origin as the security principal • Origin = domain name + protocol + port • all three must be equal for origin to be considered the same docsity.com Problems with S-O Policy • Poorly enforced on some browsers • Particularly older browsers • Limitations if site hosts unrelated pages • Example: Web server often hosts sites for unrelated parties • http://www.example.com/account/ • http://www.example.com/otheraccount/ • Same-origin policy allows script on one page to access properties of document from another • Can be bypassed in Cross-Site-Scripting attacks • Usability: Sometimes prevents desirable cross-origin resource sharing docsity.com Cross Site Scripting (XSS) • Recall the basics • scripts embedded in web pages run in browsers • scripts can access cookies • get private information • and manipulate DOM objects • controls what users see • scripts controlled by the same-origin policy • Why would XSS occur • Web applications often take user inputs and use them as part of webpage (these inputs can have scripts) docsity.com How XSS Works on Online Blog • Everyone can post comments, which will be displayed to everyone who view the post • Attacker posts a malicious comment that includes scripts (which reads local authentication credentials and send of to the attacker) • Anyone who view the post can have local authentication cookies stolen • Web apps will check that posts do not include scripts, but the check sometimes fail. • Bug in the web application. Attack happens in browser. docsity.com Avoiding XSS bugs (PHP) • Main problem: • Input checking is difficult --- many ways to inject scripts into HTML. • Preprocess input from user before echoing it • PHP: htmlspecialchars(string) &  &amp; "  &quot; '  &#039; <  &lt; >  &gt; • htmlspecialchars( "<a href='test'>Test</a>", ENT_QUOTES); Outputs: &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt; docsity.com Avoiding XSS bugs (ASP.NET) • ASP.NET 1.1: • Server.HtmlEncode(string) • Similar to PHP htmlspecialchars • validateRequest: (on by default) • Crashes page if finds <script> in POST data. • Looks for hardcoded list of patterns. • Can be disabled: <%@ Page validateRequest=“false" %> docsity.com Cross site request forgery docsity.com GMail Incidence: Jan 2007 • Google docs has a script that run a callback function, passing it your contact list as an object. The script presumably checks a cookie to ensure you are logged into a Google account before handing over the list. • Unfortunately, it doesn’t check what page is making the request. So, if you are logged in on window 1, window 2 (an evil site) can make the function call and get the contact list as an object. Since you are logged in somewhere, your cookie is valid and the request goes through. docsity.com Real World CSRF Vulnerabilities • Gmail • NY Times • ING Direct (4th largest saving bank in US) • YouTube • Various DSL Routers • Purdue WebMail • PEFCU • Purdue CS Portal • … docsity.com Prevention • Server side: • use cookie + hidden fields to authenticate • hidden fields values need to be unpredictable and user-specific • requires the body of the POST request to contain cookies • User side: • logging off one site before using others • selective sending of authentication tokens with requests docsity.com