DOCSLIB.ORG

Draft Application Security Developer's Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Draft Application Security Developer's Guide DRAFT APPLICATION SECURITY DEVELOPER’S GUIDE Version 1.0 October 4, 2002 Applications and Computing Security Division Center for Information Assurance Applications 5275 Leesburg Pike Falls Church, VA 22041 (This document is for review. Comments, if any, can be sent to [email protected] or [email protected]) FOR INFORMATIONAL PURPOSES Draft TABLE OF CONTENTS Page Number 1.0 INTRODUCTION................................................................................................................... 1 1.1 PURPOSE............................................................................................................................ 1 1.2 SCOPE ................................................................................................................................. 2 1.2.1 Subjects Not Addressed in This Document ................................................................... 2 1.3 INTENDED AUDIENCE ................................................................................................... 3 1.4 NOTE ON STYLE .............................................................................................................. 4 2.0 BACKGROUND ..................................................................................................................... 5 2.1 ORGANIZATION AND CONTENT OF THIS DOCUMENT ...................................... 5 2.2 HOW TO USE THIS DOCUMENT ................................................................................. 6 3.0 WHAT IS WEB APPLICATION SECURITY? ................................................................ 13 3.1 SECURITY IN THE WEB APPLICATION ARCHITECTURE ................................ 14 3.1.1 Application Layer ........................................................................................................ 16 3.1.2 Application Program Interface..................................................................................... 16 3.1.3 Middleware Layers ...................................................................................................... 16 3.1.4 Infrastructure................................................................................................................ 16 3.2 SECURITY-AWARE DEVELOPMENT....................................................................... 17 3.2.1 Use a Security-Oriented Development Process and Methodology.............................. 17 3.2.1.1 SSE-CMM............................................................................................................. 19 3.2.2 Adopting an Effective Security Philosophy................................................................. 19 3.2.3 Planning the Development Effort Realistically ........................................................... 20 3.2.4 Security Quality Assurance Throughout the Life Cycle.............................................. 20 3.2.5 Accurate, Complete Specifications.............................................................................. 20 3.2.6 Secure Design .............................................................................................................. 21 3.2.6.1 Minimize Functionality......................................................................................... 21 3.2.6.2 Minimize Component Size and Complexity......................................................... 23 3.2.6.3 Minimize Trusted Components............................................................................. 23 3.2.6.4 Minimize Interfaces and Outputs.......................................................................... 23 3.2.6.5 Avoid High-Risk Web Services, Protocols, and Components.............................. 23 3.2.6.6 Disable or Remove Unused Capabilities and Resources...................................... 24 3.2.6.7 Separate Data and Control .................................................................................... 24 3.2.6.8 Protect All Sensitive Transactions........................................................................ 24 3.2.6.9 Protect Sensitive Data at Rest............................................................................... 24 3.2.6.10 Include Trustworthy Authentication and Authorization..................................... 25 3.2.6.11 Always Assume the Operating Environment Is Hostile ..................................... 25 3.2.6.12 Always Assume that Third-Party Software Is Hostile........................................ 25 3.2.6.13 Never Trust Users and Browsers ........................................................................ 26 3.2.6.14 Require and Authorize No Privileged Users or User Processes ......................... 26 3.2.6.15 Do Not Rely on Security Through Obscurity ..................................................... 26 ii FOR INFORMATIONAL PURPOSES Draft 3.2.6.16 Be Accurate in Your Assumptions About the Underlying Platform .................. 27 3.2.6.17 Make Security Mechanisms Easy to Configure and Use.................................... 27 3.2.6.18 Risk Analysis of Application Design.................................................................. 27 3.2.7 Application Middleware Frameworks ......................................................................... 27 3.2.8 Restricting the Development Environment.................................................................. 28 3.2.9 Writing Elegant Software ............................................................................................ 28 3.2.9.1 Document First...................................................................................................... 28 3.2.9.2 Keep Code Simple, Small, and Easy to Follow.................................................... 29 3.2.9.3 Isolate Security Functionality ............................................................................... 29 3.2.9.4 Be Careful with Multitasking and Multithreading................................................ 29 3.2.9.5 Use Secure Data Types ......................................................................................... 30 3.2.9.6 Reuse Proven Secure Code ................................................................................... 30 3.2.9.7 Use Secure Programming Languages and Development Tools............................ 30 3.2.9.8 Call Safely to External Resources ........................................................................ 31 3.2.9.9 Use Escape Codes with Extreme Caution............................................................. 32 3.2.9.10 Maintain a Consistent Coding Style ................................................................... 33 3.2.9.11 Find and Remove Bugs....................................................................................... 33 3.2.9.12 Write for Reuse................................................................................................... 34 3.2.9.13 Keep Third-Party Component Fixes and Security Patches Up to Date .............. 34 3.2.9.14 Common Logic Errors to Avoid ......................................................................... 35 3.2.10 Security-Aware Testing ............................................................................................. 36 3.2.10.1 Rules of Thumb for Security-Aware Testing...................................................... 36 3.2.10.2 Code Reviews ..................................................................................................... 37 3.2.10.3 Source Code Security Audits.............................................................................. 38 3.2.10.4 Penetration Testing During Development .......................................................... 38 4.0 IMPLEMENTING SECURITY MECHANISMS ............................................................. 40 4.1 PUBLIC KEY-ENABLING ............................................................................................. 40 4.1.1 PK-Enabling: A Definition .......................................................................................... 41 4.1.2 Why PK-Enable? ......................................................................................................... 42 4.1.3 When to PK-Enable ..................................................................................................... 42 4.1.4 PK-Enabling Web Applications................................................................................... 44 4.1.4.1 Choosing an SSL 3.0 Tolerant Web Server.......................................................... 45 4.1.5 PK-Enabling Backend Applications: PKI Toolkits ..................................................... 46 4.2 IDENTIFICATION AND AUTHENTICATION MECHANISMS ............................. 46 4.2.1 Notification of Authentication..................................................................................... 47 4.2.2 Client (Browser)-to-Server Trusted Path..................................................................... 48 4.2.2.1 Extending the Chain of Trust to a Backend Server .............................................. 50 4.2.3 PKI-Based I&A............................................................................................................ 50 4.2.3.1 Browser Use of Hardware Tokens........................................................................ 51 4.2.4 Reusable (Static) Password I&A ................................................................................. 51 4.2.4.1 Implementing Reusable Password I&A in Web Applications.............................. 52 4.2.4.2 Confidentiality and Integrity of Usernames and Passwords................................
Load more

Recommended publications
  • IBM Multi-Factor Authentication for Z/OS
    Multi Factor Authentication for Linux on IBM Z using a centralized z/OS LDAP infrastructure Dr. Manfred Gnirss Thomas Wienert Z ATS IBM Systems IBM Germany R & D Boeblingen, 18.7.2018 © 2018 IBM Corporation 2 Trademarks The following are trademarks of the International Business Machines Corporation in the United States, other countries, or both. Not all common law marks used by IBM are listed on this page. Failure of a mark to appear does not mean that IBM does not use the mark nor does it mean that the product is not actively marketed or is not significant within its relevant market. Those trademarks followed by ® are registered trademarks of IBM in the United States; all others are trademarks or common law marks of IBM in the United States. For a complete list of IBM Trademarks, see www.ibm.com/legal/copytrade.shtml: *BladeCenter®, DB2®, e business(logo)®, DataPower®, ESCON, eServer, FICON, IBM®, IBM (logo)®, MVS, OS/390®, POWER6®, POWER6+, POWER7®, Power Architecture®, PowerVM®, S/390®, System p®, System p5, System x®, System z®, System z9®, System z10®, WebSphere®, X-Architecture®, zEnterprise, z9®, z10, z/Architecture®, z/OS®, z/VM®, z/VSE®, zSeries® The following are trademearks or registered trademarks of other companies. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc.
    [Show full text]
  • Anonymity in a Time of Surveillance
    LESSONS LEARNED TOO WELL: ANONYMITY IN A TIME OF SURVEILLANCE A. Michael Froomkin* It is no longer reasonable to assume that electronic communications can be kept private from governments or private-sector actors. In theory, encryption can protect the content of such communications, and anonymity can protect the communicator’s identity. But online anonymity—one of the two most important tools that protect online communicative freedom—is under practical and legal attack all over the world. Choke-point regulation, online identification requirements, and data-retention regulations combine to make anonymity very difficult as a practical matter and, in many countries, illegal. Moreover, key internet intermediaries further stifle anonymity by requiring users to disclose their real names. This Article traces the global development of technologies and regulations hostile to online anonymity, beginning with the early days of the Internet. Offering normative and pragmatic arguments for why communicative anonymity is important, this Article argues that anonymity is the bedrock of online freedom, and it must be preserved. U.S. anti-anonymity policies not only enable repressive policies abroad but also place at risk the safety of anonymous communications that Americans may someday need. This Article, in addition to providing suggestions on how to save electronic anonymity, calls for proponents of anti- anonymity policies to provide stronger justifications for such policies and to consider alternatives less likely to destroy individual liberties. In
    [Show full text]
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
    [Show full text]
  • XML Signature/Encryption — the Basis of Web Services Security
    Special Issue on Security for Network Society Falsification Prevention and Protection Technologies and Products XML Signature/Encryption — the Basis of Web Services Security By Koji MIYAUCHI* XML is spreading quickly as a format for electronic documents and messages. As a consequence, ABSTRACT greater importance is being placed on the XML security technology. Against this background research and development efforts into XML security are being energetically pursued. This paper discusses the W3C XML Signature and XML Encryption specifications, which represent the fundamental technology of XML security, as well as other related technologies originally developed by NEC. KEYWORDS XML security, XML signature, XML encryption, Distributed signature, Web services security 1. INTRODUCTION 2. XML SIGNATURE XML is an extendible markup language, the speci- 2.1 Overview fication of which has been established by the W3C XML Signature is an electronic signature technol- (WWW Consortium). It is spreading quickly because ogy that is optimized for XML data. The practical of its flexibility and its platform-independent technol- benefits of this technology include Partial Signature, ogy, which freely allows authors to decide on docu- which allows an electronic signature to be written on ment structures. Various XML-based standard for- specific tags contained in XML data, and Multiple mats have been developed including: ebXML and Signature, which enables multiple electronic signa- RosettaNet, which are standard specifications for e- tures to be written. The use of XML Signature can commerce transactions, TravelXML, which is an EDI solve security problems, including falsification, spoof- (Electronic Data Interchange) standard for travel ing, and repudiation. agencies, and NewsML, which is a standard specifica- tion for new distribution formats.
    [Show full text]
  • RSA BSAFE Crypto-C 5.21 FIPS 140-1 Security Policy2.…
    RSA Security, Inc. RSA™ BSAFE® Crypto-C Crypto-C Version 5.2.1 FIPS 140-1 Non-Proprietary Security Policy Level 1 Validation Revision 1.0, May 2001 © Copyright 2001 RSA Security, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents 1 INTRODUCTION.................................................................................................................. 3 1.1 PURPOSE ............................................................................................................................. 3 1.2 REFERENCES ....................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................... 3 2 THE RSA BSAFE PRODUCTS............................................................................................ 5 2.1 THE RSA BSAFE CRYPTO-C TOOLKIT MODULE .............................................................. 5 2.2 MODULE INTERFACES ......................................................................................................... 5 2.3 ROLES AND SERVICES ......................................................................................................... 6 2.4 CRYPTOGRAPHIC KEY MANAGEMENT ................................................................................ 7 2.4.1 Protocol Support........................................................................................................
    [Show full text]
  • XML for Java Developers G22.3033-002 Course Roadmap
    XML for Java Developers G22.3033-002 Session 1 - Main Theme Markup Language Technologies (Part I) Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Course Roadmap Consider the Spectrum of Applications Architectures Distributed vs. Decentralized Apps + Thick vs. Thin Clients J2EE for eCommerce vs. J2EE/Web Services, JXTA, etc. Learn Specific XML/Java “Patterns” Used for Data/Content Presentation, Data Exchange, and Application Configuration Cover XML/Java Technologies According to their Use in the Various Phases of the Application Development Lifecycle (i.e., Discovery, Design, Development, Deployment, Administration) e.g., Modeling, Configuration Management, Processing, Rendering, Querying, Secure Messaging, etc. Develop XML Applications as Assemblies of Reusable XML- Based Services (Applications of XML + Java Applications) 2 1 Agenda XML Generics Course Logistics, Structure and Objectives History of Meta-Markup Languages XML Applications: Markup Languages XML Information Modeling Applications XML-Based Architectures XML and Java XML Development Tools Summary Class Project Readings Assignment #1a 3 Part I Introduction 4 2 XML Generics XML means eXtensible Markup Language XML expresses the structure of information (i.e., document content) separately from its presentation XSL style sheets are used to convert documents to a presentation format that can be processed by a target presentation device (e.g., HTML in the case of legacy browsers) Need a
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Introduction to XML
    Introduction to XML CS 317/387 Agenda – Introduction to XML 1. What is it? 2. What’s it good for? 3. How does it work? 4. The infrastructure of XML 5. Using XML on the Web 6. Implementation issues & costs 2 1. What is it? Discussion points: First principles: OHCO Example: A simple XML fragment Compare/contrast: SGML, HTML, XHTML A different XML for every community Terminology 3 1 Ordered hierarchies of content objects Premise: A text is the sum of its component parts A <Book> could be defined as containing: <FrontMatter>, <Chapter>s, <BackMatter> <FrontMatter> could contain: <BookTitle> <Author>s <PubInfo> A <Chapter> could contain: <ChapterTitle> <Paragraph>s A <Paragraph> could contain: <Sentence>s or <Table>s or <Figure>s … Components chosen should reflect anticipated use 4 Ordered hierarchies of content objects OHCO is a useful, albeit imperfect, model Exposes an object’s intellectual structure Supports reuse & abstraction of components Better than a bit-mapped page image Better than a model of text as a stream of characters plus formatting instructions Data management system for document-like objects Does not allow overlapping content objects Incomplete; requires infrastructure 5 Content objects in a book Book FrontMatter BookTitle Author(s) PubInfo Chapter(s) ChapterTitle Paragraph(s) BackMatter References Index 6 2 Content objects in a catalog card Card CallNumber MainEntry TitleStatement TitleProper StatementOfResponsibility Imprint SummaryNote AddedEntrySubject(s) Added EntryPersonalName(s) 7 Semistructured Data Another data model, based on trees. Motivation: flexible representation of data. Often, data comes from multiple sources with differences in notation, meaning, etc. Motivation: sharing of documents among systems and databases.
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • 1 Term of Reference Reference Number TOR-VNM-2021-21
    Term of Reference Reference number TOR-VNM-2021-21 (Please refer to this number in the application) Assignment title International Gender Consultant Purpose to develop a technical paper comparing legal frameworks and setting out good practices for legal recognition of gender identity/protection of the human rights of trans persons in other countries/regions. Location Home-based Contract duration 1 June 2021 – 31 August 2021 (32 working days) Contract supervision UN Women Programme Specialist UN Women Viet Nam Country Office I. Background UN Women Grounded in the vision of equality enshrined in the Charter of the United Nations, the United Nations Entity for Gender Equality and the Empowerment of Women (UN Women) works for the elimination of discrimination against women and girls; the empowerment of women; and the achievement of substantive equality between women and men. The fundamental objective of UN Women is to enhance national capacity and ownership to enable national partners to formulate gender responsive laws, policies and upscale successful strategies to deliver on national and international commitments to gender equality. UN Women Viet Nam Country Office is the chair of the UN Gender Theme Group and has been an active member of the UN Human Rights Thematic Group (HRTG) and Viet Nam UN HIV Thematic Group and acts as a leading agency in related to promoting gender equality in the national HIV response. The result under this LOA will contribute to the achievements of the following outcome and output of UN Women Viet Nam’s Annual Work Plan. - VCO Impact 3 (SP outcome 4): Women and girls live a life free from violence.
    [Show full text]
  • Web API Protocol and Security Analysis Web
    EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2017 Web API protocol and security analysis Web API protokoll- och säkerhetsanalys CRISTIAN ARAYA MANJINDER SINGH KTH SKOLAN FÖR TEKNIK OCH HÄLSA Web API protocol and security analysis Web API protokoll- och säkerhetsanalys Cristian Araya and Manjinder Singh Degree project in Computer science First level, 15hp Supervisor from KTH: Reine Bergström Examiner: Ibrahim Orhan TRITA-STH 2017:34 KTH The School of Technology and Health 141 52 Flemingsberg, Sweden Abstract There is problem that every company has its own customer portal. This problem can be solved by creating a platform that gathers all customers’ portals in one place. For such platform, it is required a web API protocol that is fast, secure and has capacity for many users. Consequently, a survey of various web API protocols has been made by testing their performance and security. The task was to find out which web API protocol offered high security as well as high performance in terms of response time both at low and high load. This included an investigation of previous work to find out if certain protocols could be ruled out. During the work, the platform’s backend was also developed, which needed to implement chosen web API protocols that would later be tested. The performed tests measured the APIs’ connection time and their response time with and without load. The results were analyzed and showed that the protocols had both pros and cons. Finally, a protocol was chosen that was suitable for the platform because it offered high security and fast connection.
    [Show full text]
  • Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
    [Show full text]