DOCSLIB.ORG

View the Index

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
View the Index INDEX Page numbers followed by an italicized Airbrake, 44 f or t refer to figures and tables Akamai, 26, 62, 138 respectively. Amazon denial-of-service attacks, 163 one-click purchases, 76 Amazon CloudFront, 26 Symbols and Numbers Amazon Elastic Compute Cloud : (colon character), 82 (EC2), 41 / (path separator character), 109 Amazon Machine Images (AMIs), 62 ; (semicolon character), 52 Amazon Simple Storage Service (S3), ' (single quote character), 51–53 62, 140 10 Minute Mail, 86 Amazon Web Services (AWS), 105, 401 status code (in HTTP), 82 137, 168 Elastic Beanstalk, 41 A Marketplace, 62 AMIs (Amazon Machine Images), 62 Accept header, 10–11 amplified attacks, 165 access control, 25, 166 Angular framework, 33–34, 72 aspects of, 104 Ansible, 42 audit trails, 107–108 anti-CSRF cookies, 77–78 common oversights, 108 antivirus software defined, 104 mitigating file upload vulnerability implementing, 106–107 attacks, 63 models for protection against botnets, 160 access control lists, 105 Apache web servers, 53, 114, 125 ownership-based access disabling open directory control, 106 listings, 137 role-based access control, disabling URL rewriting, 100 105–106 injection attacks, 132 whitelists and blacklists, 105 application firewalls, 166 testing, 107 application layer attacks, 165 access control lists (ACLs), 105 application programming interface access tokens, 139 (API) keys, 139 Acid3 test, 18, 18f application servers, 125–126 Active Directory, 137 ARPANET (Advanced Research ActiveRecord framework, 54–55 Projects Agency Network), 7 ActiveX, xxi asymmetric encryption algorithms, 119 administrative frontends, securing, 138 audit trails, 107–108 ad platforms, 142 authentication Advanced Encryption Standard (AES), brute-force attacks, 83–84 121, 138 databases and, 29 Advanced Research Projects Agency defined, 81 Network (ARPANET), 7 authentication (continued) C implementing C# basic authentication build process, 42 scheme, 82 overview of, 33 digest authentication vulnerabilities, 33 scheme, 82 C++, 33 HTTP-native authentication, Cache-Control header, 13 82–83, 83f canonical name (CNAME) records, 9 non-native authentication, 83 CAPTCHA (Completely Automated mitigation options Public Turing test to tell secure authentication system, Computers and Humans 85–92 Apart), 91–92, 92f, 158 single sign-on, 84–85 Cascading Style Sheets (CSS) third-party authentication, 84 build process, 43 authenticator apps, 90, 90f in HTTP responses, 13 Authorization header, 82 pre-processors, 43 AVG, 132 selectors, 17 AWS. See Amazon Web Services (AWS) stylesheets, 17 styling rules, 17 B use in clickjacking attacks, 158 Bachus-Naur Form (BNF), 147 CDNs. See content delivery Base64 algorithm, 82 networks (CDNs) bcrypt algorithm, 88–89 Center for Internet Security (CIS), 62 Berners-Lee, Tim, xx–xxi, 24 centralized version control systems, 37 bind parameters Centrify, 84 object-relational mapping, 54 CEO fraud, 154 parameterized statements, 52–53 CERN (European Organization for Bitly, 156 Nuclear Research), xx–xxi black hat hackers, 2 certificate authorities, 117, 122–125 blacklists, 105 certificate signing requests (CSRs), blind SQL injection attacks, 56 123–124 block ciphers, 119–120 CGI (Common Gateway Interface), xxii BNF (Bachus-Naur Form), 147 checksums, 8, 40, 134 botnets, xxii, 154, 160, 165 Chef, 42 branching code, 38 chroot command, 58 brittleness, 39 CIS (Center for Internet Security), 62 browsers Cisco, 128 cookies, 20 cleartext storage, 88 Document Object Model, 16–17 click fraud, 160 Domain Name System, 20 clickjacking, 154, 158–159 HTTP Secure, 20 client-server architecture, 49 JavaScript, 16, 18–19 client-side error reporting, 115 security certificates, 20 client-side sessions, 96–97 styling rules, 16–18 Clojure, 32 web page rendering pipeline, 15–19 cloud-based storage brute-force attacks, 100 hosting services, 110–111 bug trackers (issue-tracking subdomain takeovers, 140 software), 36 use in mitigating file upload building for scale, 167, 173 vulnerability attacks, 62 bundler-audit tool, 136 Cloudflare, 26, 62 CLR (Common Language Runtime), 33 174 Index CMSs. See content management Cookie header, 13, 77–78, 97 systems (CMSs) cookies, 171 CNAME (canonical name) records, 9 anti-CSRF cookies, 77–78 code reviews, 38, 170 defined, 13 code writing phase (in the software digital signing of, 96–97 development lifecycle) generic cookie parameters, 114 branching and merging code, 38 implementing and securing a pushing changes to repository, 37 logout function, 90–91 source control (version control), 37 SameSite cookie attribute, 78–79 CoffeeScript, 34, 42 session cookies, 95–97, 114 colon character (:), 82 session hijacking, 97–99 Comcast, 128 vulnerabilities of, 13 command injection attacks cookie theft anatomy of, 56–57, 57f cross-site request forgery (CSRF) defined, 56 attacks, 98–99 escaping control characters, 57–58 cross-site scripting (XSS) attacks, file upload vulnerability and, 61 97–98 Common Gateway Interface (CGI), xxii man-in-the-middle attacks, 98 Common Language Runtime (CLR), 33 cracking password lists, 89 Comodo, 122 CREATE statements (in SQL), 55 Completely Automated Public Turing cross-site request forgery (CSRF; test to tell Computers and XSRF) attacks Humans Apart (CAPTCHA), anatomy of, 76 91–92, 92f, 158 cookie theft, 98–99 CONNECT requests (in TCP), 11t defined, 75 consistent behavior mitigation options eventual consistency of NoSQL anti-CSRF cookies, 77–78 databases, 30 requiring reauthentication for SQL databases, 29 sensitive actions, 78–79 containerization, 42 REST principles, 76–77 content delivery networks (CDNs), 26 SameSite cookie attribute, distributed denial-of-service protect 78–79 systems, 167 cross-site scripting (XSS) attacks, mitigating file upload vulnerability xxi, 19 attacks, 62, 170 cookie theft, 97–98 subdomain takeovers, 140 defined, 65 content management systems (CMSs) DOM-based defined, 26 defined, 71 mitigating file upload vulnerability escaping dynamic content, 73 attacks, 62, 170 URI fragments, 71–73 plug-ins, 26 reflected, 70–71 vulnerabilities of, 26, 27f defined, 70 content security policies, 69–70, escaping dynamic content, 71 110–111 stored Content-Security-Policy header, 69, content security policies, 69–70 158–159, 172 escaping control characters, Content-Type header, 13, 59, 63 67–69 continuous integration servers, 39 example of, 66–67, 66f–67f control characters cryptographic hash algorithms and in PHP, 56–58 functions, 88–89, 119 in SQL, 51–53, 55 cryptography, 117 Index 175 CSRF attacks. See cross-site request reflected and amplified forgery (CSRF) attacks attacks, 165 CSRs (certificate signing requests), Transmission Control Protocol 123–124 (TCP) attacks, 164 CSS. See Cascading Style Sheets (CSS) unintentional denial-of-service attacks, 166 D dependencies, 171 build process, 42 database administrators (DBAs), 43 defined, 45 database drivers, 51 deploying new versions quickly, 134 database migration scripts, 43 organizing dependencies databases dependency management tools, authentication and, 29 132–133 for building dynamic web pages, operating system patches, 28–30 133–134 NoSQL, 30 subresource integrity checks, 134 origin of, 28 security advisories SQL, 29–30, 105 blogs, 135 stored cross-site scripting attacks, 66 mailing lists, 135 data definition language (DDL), 55 official advisories, 135 data integrity, 29, 118 social media, 135 data manipulation language (DML), 55 software tools, 136 data packets, 8 timely upgrades, 136 DBAs (database administrators), 43 vulnerability of, 45 DDL (data definition language), 55 dependency-check tool, 136 DDoS (distributed denial-of-service) dependency management, 45, 132–133 attacks, 165, 167 dependency trees, 133 decryption keys, 118–119 deserialization dedicated configuration stores, 137 defined, 59 default credentials, disabling, 137 disabling code-execution during, defense in depth approach, 61 59–60 blind and nonblind SQL injection, design and analysis phase, 36 55–56 DevOps (developer operations) tools, defined, 55 41–42 principle of least privilege, 55 DigiCert, 122 defer attribute, 19 digital certificates (public-key DELETE requests (in SQL), 11, 76–77 certificates) DELETE statements (in SQL), 50–51, 55 certificate authorities, 122–123 denial-of-service (DoS) attacks defined, 122 defined, 163–164 installing mitigation options configuring web server to use building for scale, 167–168 HTTPS, 126 firewalls, 166 HTTP Strict Transport Security intrusion prevention systems, 166 policies, 127 protection services, 167 redirecting HTTP traffic to types of HTTPS, 126–127 application layer attacks, 165 web servers vs. application distributed denial-of-service servers, 125–126 attacks, 165 obtaining Internet Control Message certificate signing requests, Protocol (ICMP) attacks, 164 123–124 domain verification, 124 176 Index expiring certificates, 124 DomainKeys Identified Mail (DKIM), extended validation 155–156, 172 certificates, 124 domain name servers, 9 key pairs, 123–124 Domain Name System (DNS) paying for certificates, 125 caching behavior, 9 revoking certificates, 124 canonical name records, 9 self-signed certificates, 124–125 DNS poisoning, 9 TLS handshakes, 121 domain verification, 124 digital signatures, 96–97 encryption, 122–123 directories, 109 Internet Protocol suite layers, 10f directory traversal attacks, xxii, mail exchange records, 9 108–112 purpose of, 9 anatomy of, 109–110, 109f–110f registration of, 9 defined, 108 rendering pipeline, 20 filepaths and relative filepaths, subdomain takeovers, 140 108–109 validating email addresses, 86
Load more

Recommended publications
  • Bibliography of Erik Wilde
    dretbiblio dretbiblio Erik Wilde's Bibliography References [1] AFIPS Fall Joint Computer Conference, San Francisco, California, December 1968. [2] Seventeenth IEEE Conference on Computer Communication Networks, Washington, D.C., 1978. [3] ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, Los Angeles, Cal- ifornia, March 1982. ACM Press. [4] First Conference on Computer-Supported Cooperative Work, 1986. [5] 1987 ACM Conference on Hypertext, Chapel Hill, North Carolina, November 1987. ACM Press. [6] 18th IEEE International Symposium on Fault-Tolerant Computing, Tokyo, Japan, 1988. IEEE Computer Society Press. [7] Conference on Computer-Supported Cooperative Work, Portland, Oregon, 1988. ACM Press. [8] Conference on Office Information Systems, Palo Alto, California, March 1988. [9] 1989 ACM Conference on Hypertext, Pittsburgh, Pennsylvania, November 1989. ACM Press. [10] UNIX | The Legend Evolves. Summer 1990 UKUUG Conference, Buntingford, UK, 1990. UKUUG. [11] Fourth ACM Symposium on User Interface Software and Technology, Hilton Head, South Carolina, November 1991. [12] GLOBECOM'91 Conference, Phoenix, Arizona, 1991. IEEE Computer Society Press. [13] IEEE INFOCOM '91 Conference on Computer Communications, Bal Harbour, Florida, 1991. IEEE Computer Society Press. [14] IEEE International Conference on Communications, Denver, Colorado, June 1991. [15] International Workshop on CSCW, Berlin, Germany, April 1991. [16] Third ACM Conference on Hypertext, San Antonio, Texas, December 1991. ACM Press. [17] 11th Symposium on Reliable Distributed Systems, Houston, Texas, 1992. IEEE Computer Society Press. [18] 3rd Joint European Networking Conference, Innsbruck, Austria, May 1992. [19] Fourth ACM Conference on Hypertext, Milano, Italy, November 1992. ACM Press. [20] GLOBECOM'92 Conference, Orlando, Florida, December 1992. IEEE Computer Society Press. http://github.com/dret/biblio (August 29, 2018) 1 dretbiblio [21] IEEE INFOCOM '92 Conference on Computer Communications, Florence, Italy, 1992.
    [Show full text]
  • Browser Security Features
    Browser Security features Michael Sonntag Institute of Networks and Security Cookies: Securing them Attention: These are “requests” by the server setting the cookie Browsers will follow them, but applications not necessarily Secure/HTTPS-only: Do not send unencrypted This is an element of the Cookie header itself “Set-Cookie: “ …content, domain, expiration… “;Secure” Often the application contains an option to set this automatically HTTP-only: No access by JavaScript This is an element of the Cookie header itself “Set-Cookie: “ …content, domain, expiration… “;HttpOnly” Host-only: Do not set the “Domain” attribute Not set: Send to exactly this host only Domain set: Send to every host at or under this domain Priority: When too many cookies from a single domain, delete those of low priority first Not really a security feature! 2 Cookies: Securing them SameSite: Cookie should not be sent with cross-site requests (some CSRF-prevention; prevent cross-origin information leakage) “Strict” : Never cross origin; not even when clicking on a link on site A leading to B the Cookie set from B is actually sent to B “Lax” (default): Sent when clicking on most links, but not with POST requests: “Same-Site” and “cross-site top-level navigation” Not as good as strict: E.g. “<link rel='prerender’>” is a same-site request fetched automatically (and kept in the background!) Sent: GET requests leading to a top-level target (=URL in address bar changes; but may contain e.g. path) I.e.: Will not be sent for iframes, images, XMLHttpRequests
    [Show full text]
  • Web Application Security Standards
    WEB APPLICATION SECURITY STANDARDS It is much more secure to be feared than to be loved. www.ideas2it.com Security Headers ● Content-Security-Policy ○ Reduce XSS risks on modern browsers ● X-Content-Type-Options ○ Prevent browsers from trying to guess (“sniff”) the MIME type ● X-XSS-Protection ○ Stops pages from loading when they detect reflected cross-site scripting (XSS) ● X-Frame-Options ○ Prevent the site from clickjacking attacks www.ideas2it.com Security Headers ● Strict-Transport-Security ○ Lets a website tell browsers that it should only be accessed using HTTPS ● Referrer-Policy ○ Controls how much referrer information (sent via the Referer header) should be included with requests. ● Feature-policy ○ Provides a mechanism to allow and deny the use of browser features. www.ideas2it.com Request : digicontent.com/assets/css/styles.css Request : digicontent.com/assets/js/filter.js Request : malicious.com/assets/js/xss.js Content-Security-Policy: default-src digicontent.com Content Security Policy Browser Asset Sniff asset to determine MIME type Based on content MIME type = HTML MIME Sniffing HSTS enabled Client origin server Request : http://digicontent.com Response : https://digicontent.com HTTP Strict Transport Security Cross Site Scripting - XSS ● Stealing other user’s cookies ● Stealing their private information ● Performing actions on behalf of other users ● Redirecting to other websites ● Showing ads in hidden IFRAMES and pop-ups www.ideas2it.com Cross Site Scripting (XSS) Secure cache control settings ● Max-age ● No-cache ● No-store ● Public ● Private ● Must-Revalidate ● Proxy-Revalidate www.ideas2it.com Request : digicontent.com/styles.css digicontent.com/styles.css Cache-Control : max-age = 3600 3600s Receive styles.css Store styles.css Browser Cache Cache-Control www.ideas2it.com Cookie attributes ● HTTP-ONLY ● SECURE ● Domain ● SameSite (Strict/Lax/None) ● Path www.ideas2it.com Cookie : Same Site Vulnerable TLS SSL vs.
    [Show full text]
  • Web Application Report
    Web Application Report This report includes important security information about your web application. Security Report This report was created by IBM Security AppScan Standard 9.0.3.13, Rules: 18533 Scan started: 6/2/2020 10:39:20 AM Table of Contents Introduction General Information Login Settings Summary Issue Types Vulnerable URLs Fix Recommendations Security Risks Causes WASC Threat Classification Issues Sorted by Issue Type Cross-Site Scripting 28 Link to Non-Existing Domain Found 2 SQL Injection File Write (requires user verification) 1 Check for SRI (Subresource Integrity) support 1 Credit Card Number Pattern Found (Visa) Over Unencrypted Connection 1 Google Sitemap File Detected 1 Hidden Directory Detected 6 Missing or insecure "Content-Security-Policy" header 5 Unsafe third-party link (target="_blank") 22 Fix Recommendations Remove the non-existing domain from the web site Review possible solutions for hazardous character injection Add the attribute rel = "noopener noreferrer" to each link element with target="_blank" 6/3/2020 1 Add to each third-party script/link element support to SRI(Subresource Integrity). Config your server to use the "Content-Security-Policy" header with secure policies Issue a "404 - Not Found" response status code for a forbidden resource, or remove it completely Remove credit card numbers from your website Validate that your Google Sitemap file only contains URLs that should be publicly available and indexed Advisories Cross-Site Scripting Link to Non-Existing Domain Found SQL Injection File Write (requires user verification) Check for SRI (Subresource Integrity) support Credit Card Number Pattern Found (Visa) Over Unencrypted Connection Google Sitemap File Detected Hidden Directory Detected Missing or insecure "Content-Security-Policy" header TargetBlankLink Application Data Cookies JavaScripts Parameters Comments Visited URLs Failed Requests Filtered URLs 6/3/2020 2 Introduction This report contains the results of a web application security scan performed by IBM Security AppScan Standard.
    [Show full text]
  • SECURE PROGRAMMING TECHNIQUES Web Application Security
    SECURE PROGRAMMING TECHNIQUES Web application security • SQL injection • Parameterized statements • Other injections • Cross-site scripting • Persistent and reflected XSS • AJAX and cross-domains access • Javascript • Cross-Site Request Forgery • Clickjacking • OAuth 2 and OpenID Connect • PHP security MEELIS ROOS 1 SECURE PROGRAMMING TECHNIQUES SQL injection • A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application • A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shut down the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system • Blind SQL injection — when you don’t get to see the query output – But you can see whether error messages appear or not, or how long the query takes MEELIS ROOS 2 SECURE PROGRAMMING TECHNIQUES Fixing SQL injection • Input filtering — only harmless input parameters allowed • Input escaping — dangerous characters are allowed but escaped • Explicit type conversions in SQL — int() etc • Parameterized statements with type-aware parameter substitution – Parameters are sent as metadata (in a structured way, not inline) – Also allows for performance gains with most databases • Stored procedures — fixes SQL query structure, parameters still might need validation MEELIS ROOS 3 SECURE PROGRAMMING TECHNIQUES Parameterized statements • Java with
    [Show full text]
  • The Web's Security Model
    The Web’s Security Model Philippe De Ryck @PhilippeDeRyck https://www.websec.be 2 The Agenda for Today § The Same-Origin Policy § Setting a baseline with very relevant 20 year old technology § Third-Party Content Integration § Frame and script-based integration § Session Management § Cookies and the unavoidable CSRF attacks § Accessing Cross-Origin APIs § Extending the SOP with server-driven policies § Conclusion 3 About Me – Philippe De Ryck § Postdoctoral Researcher @ DistriNet (KU Leuven) § PhD on client-side Web security § Expert in the broad field of Web security § Main author of the Primer on Client-Side Web Security § Running the Web Security training program § Dissemination of knowledge and research results § Public training courses and targeted in-house training § Target audiences include industry and researchers @PhilippeDeRyck https://www.websec.be 4 The Same-Origin Policy 5 Same-Origin Policy § Separation based on origin § Default security policy enforced by the browser § Restricts the interactions between contexts of different origins § Protects applications from unintended interactions § First appeared in browsers in 1995, and still going strong ORIGIN SAME-ORIGIN POLICY The triple <scheme, host, port> Content retrieved from one derived from the document’s URL. origin can freely interact with For http://example.org/forum/, the other content from that origin, origin is <http, example.org, 80> but interactions with content from other origins are restricted 6 Examples of the Same-Origin Policy http://example.com SAME-ORIGIN POLICY http://example.com Content retrieved from one origin can freely interact with other content from that origin, but interactions with content http://forum.example.com from other origins are restricted http://private.example.com 7 Domains vs Subdomains § Subdomains § E.g.
    [Show full text]
  • An Empirical Study of the Use of Integrity Verification Mechanisms
    An Empirical Study of the Use of Integrity Verification Mechanisms for Web Subresources Bertil Chapuis, Olamide Omolola, Mauro Cherubini, Mathias Humbert, Kévin Huguenin To cite this version: Bertil Chapuis, Olamide Omolola, Mauro Cherubini, Mathias Humbert, Kévin Huguenin. An Empiri- cal Study of the Use of Integrity Verification Mechanisms for Web Subresources. The Web Conference (WWW), Apr 2020, Taipei, Taiwan. pp.34-45, 10.1145/3366423.3380092. hal-02435688 HAL Id: hal-02435688 https://hal.archives-ouvertes.fr/hal-02435688 Submitted on 20 Jan 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. An Empirical Study of the Use of Integrity Verification Mechanisms for Web Subresources Bertil Chapuis Olamide Omolola Mauro Cherubini UNIL – HEC Lausanne TU Graz UNIL – HEC Lausanne Switzerland Austria Switzerland [email protected] [email protected] [email protected] Mathias Humbert Kévin Huguenin armasuisse S+T UNIL – HEC Lausanne Switzerland Switzerland [email protected] [email protected] ABSTRACT 1 INTRODUCTION Web developers can (and do) include subresources such as scripts, The Web is a set of interlinked resources identied by their URLs. stylesheets and images in their webpages.
    [Show full text]
  • Course Notes-Advanced Web Securityp1
    Match the attack to its description: Attacks: 8 Using Components with Known Vulnerabilities 7 Missing Function Level Access Control 5 Sensitive Data Exposure Descriptions: 6 Security Misconfiguration 1. Modifies back-end statement through user input. 4 Insecure Direct Object References 2. Inserts Javascript into trusted sites. 2 Cross Site Scripting 3. Program flaws allow bypass of authentication 3 Broken Authentication and Session methods. 1 Injection 4. Attackers modify file names. 5. Abuses lack of data encryption. 6. Exploits misconfigured servers. 7. Privilege functionality is hidden rather than enforced through access controls. 8. Uses unpatched third party components. Goals of Web Security: Browse the web safely Support secure web applications Applications delivered over No stolen information the web should be able to Site A cannot compromise achieve the same security session at site B properties as stand alone applications Threat Models Web Security Network Security Threat Model: Threat Model: Attacker sets up a Attacker intercepts malicious site and controls network Attacker does not control the network Rank these in order, 1 for the most common, 10 for the least common: 5 Security Misconfiguration 4 Insecure Direct Object References 7 Missing Function Level Access Control 6 Sensitive Data Exposure 9 Using Components with Known Vulnerabilities 3 Cross Site Scripting 10 Unvalidated Redirects and Forwards 2 Broken Authentication and Session 1 Injection 8 Cross Site request Forgery Web Threat Models Web Attacker: Control attacker.com
    [Show full text]
  • Web Publications W3C Working Group Note 13 August 2019
    Web Publications W3C Working Group Note 13 August 2019 This version: https://www.w3.org/TR/2019/NOTE-wpub-20190813/ Latest published version: https://www.w3.org/TR/wpub/ Latest editor's draft: https://w3c.github.io/wpub/ Previous version: https://www.w3.org/TR/2019/WD-wpub-20190614/ Editors: Matt Garrish (DAISY Consortium) Ivan Herman (W3C) Participate: GitHub w3c/wpub File a bug Commit history Pull requests Copyright © 2019 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply. Abstract The primary objective of this specification is to define requirements for the production of Web Publications. In doing so, it also defines a framework for creating packaged publication formats, such as EPUB and audiobooks, where a pathway to the Web is highly desirable but not necessarily the primary method of interchange or consumption. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/. Due to the lack of practical business cases for Web Publications, and the consequent lack of commitment to implement the technology, the Publishing Working Group has chosen to publish this document as a Note and focus on other areas of interest, including developing the manifest format as a separate specification. This document was still a work in progress at the time of its publication. As a result, anyone seeking to create Web Publications, or implement a reader for them, should read the approach and proposals outlined in this document with an abundance of caution.
    [Show full text]
  • Cure53 Browser Security White Paper
    Dr.-Ing. Mario Heiderich, Cure53 Bielefelder Str. 14 D 10709 Berlin cure53.de · [email protected] Cure53 Browser Security White Paper Dr.-Ing. Mario Heiderich Alex Inführ, MSc. Fabian Fäßler, BSc. Nikolai Krein, MSc. Masato Kinugawa Tsang-Chi "Filedescriptor" Hong, BSc. Dario Weißer, BSc. Dr. Paula Pustułka Cure53, Berlin · 29.11.17 1/330 Dr.-Ing. Mario Heiderich, Cure53 Bielefelder Str. 14 D 10709 Berlin cure53.de · [email protected] List of Tables .............................................................................................................................. 3 List of Figures ............................................................................................................................ 5 Chapter 1. Introducing Cure53 BS White Paper ......................................................................... 7 Browser Security Landscape: An Overview ............................................................................ 9 The Authors .......................................................................................................................13 The Sponsor ......................................................................................................................15 Earlier Projects & Related Work .........................................................................................15 Research Scope ................................................................................................................16 Version Details ...................................................................................................................19
    [Show full text]
  • Browser Code Isolation
    CS 155 Spring 2016 Browser code isolation John Mitchell Modern web sites are complex Modern web “site” Code from many sources Combined in many ways Sites handle sensitive information Financial data n Online banking, tax filing, shopping, budgeting, … Health data n Genomics, prescriptions, … Personal data n Email, messaging, affiliations, … Goal: prevent malicious web content from stealing information. Basic questions How do we isolate code from different sources n Protecting sensitive information in browser n Ensuring some form of integrity n Allowing modern functionality, flexible interaction More specifically How do we protect page from ads/services? How to share data with cross-origin page? How to protect one user from another’s content? How do we protect the page from a library? How do we protect page from CDN? How do we protect extension from page? Recall Same-Origin Policy (SOP) Idea: Isolate content from different origins n Restricts interaction between compartments n Restricts network request and response Recall Same-Origin Policy (SOP) Recall Same-Origin Policy (SOP) Recall Same-Origin Policy (SOP) XmlHttpRequest follows same-origin policy Recall Same-Origin Policy (SOP) Same-origin policy summary Isolate content from different origins n E.g., can’t access document of cross-origin page n E.g., can’t inspect responses from cross-origin Example:Library Library included using tag n <script src="jquery.js"></script> No isolation n Runs in same frame, same origin as rest of page May contain arbitrary code n Library developer errors
    [Show full text]
  • MS-IEDOCO]: Internet Explorer Standards Support Documentation Overview
    [MS-IEDOCO]: Internet Explorer Standards Support Documentation Overview Intellectual Property Rights Notice for Open Specifications Documentation . Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected].
    [Show full text]