Digital Library

Software Security for Developers (MEAP) With examples in Java and Spring (Adib Saikali, Laurențiu Spilcă)（Z-Library）

,

Share E-Book
Read Without Registration

Software Security for Developers (MEAP) With examples in Java and Spring (Adib Saikali, Laurențiu Spilcă)（Z-Library）

Author

,

Software
Language English

Cloud applications have special security requirements and concerns. This book demonstrates effective real-world practices to keep your cloud and Kubernetes-deployed applications safe and sound. In Software Security for Developers you will learn how to: Configure industry standard security protocols correctly Quickly debug errors and exceptions form security libraries Utilize the developer-friendly Google Tink cryptography library Work with X.509 digital certificates for implementing application security Setup passwordless logins using the WebAuthentication protocol Implement single sign on using OpenID Connect protocol Establish authentication and authorization services using the Spring Authorization Server Make use of popular secret storage solutions including HashiCorp Vault, AWS KMS, Google KMS, and Azure Key Vault Use the security features of Kubernetes to secure deployed applications Securely containerize application code Software Security for Developers is a hands-on guide for working developers. It minimizes the abstract and complex security theory, instead focusing on the practices you need to secure applications running on Kubernetes and the cloud. In it, you’ll learn how to take advantage of pre-built security services in your daily development. Author Adib Saikali takes a developer-to-developer approach, sharing hard-won lessons from many years securing software in real-world environments. Easy-to-follow sample applications written in Java take you hands-on with security standards and protocols, turning complex concepts into practical solutions. about the reader For intermediate Java developers ready to up their security skills.

Format PDF
Size 19.6 MB
12
Views
(First 20 pages)

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

Page 1
(This page has no text content)
Page 2
(This page has no text content)
Page 3
Software Security for Developers 1. welcome 2. Part_1_Application_Security_the_Big_Picture 3. 1_Making_Sense_of_Application_Security 4. 2_Standards_for_implementing_authentication 5. 3_Service-to-service_communication 6. Part_2_Cryptography_Foundations 7. 4_Message_Integrity_and_Authentication 8. 5_Advanced_Encryption_Standard 9. 6_JSON_Object_Signing_and_Encryption_(JOSE) 10. 7_Public_Key_Encryption_and_Digital_Signatures:_Unleashing_RSA 11. 8_Public_Key_Encryption_and_Digital_Signatures:_Using_ECC 12. 9_Public_Key_Infrastructure_and_X.509_Digital_Certificates:_know_who_you_are_talking_to 13. 10_Working_with_X.509_Certificates:_Lifecycle_and_Self-Signing 14. 11_Transport_Layer_Security_(TLS):_How_the_internet_is_secured 15. 12_Single_Sign_On_(SSO)_using_OAuth2_and_OpenID_Connect 16. 13_Deepening_security_with_OpenID_Connect 17. 14_Passwordless_login:_Using_Magic_links_and_OTPs 18. 15_Passwordless_login:_WebAuthn_and_hardware_authentication
Page 4
welcome Thank you for purchasing the MEAP edition of Software Security for Developers: With examples in Java and Spring. This book is for developers who want to learn application security in a practical way using sample applications to explore complex security protocols, algorithms, and patterns. Over the past 20 years I have implemented security on numerous applications, which meant correctly configuring and using a variety of security libraries and protocols. For example, implementing Single Sign On using SAML or OpenID Connect, or encrypting files with AES, or configuring TLS cipher suites on a tomcat server. I frequently got stuck on security related error messages I did not understand, on security APIs that seemed hard to use, so I invested a lot of time and effort to learn security. This meant a lot of time and effort reading a lot of books with a lot of math in them to learn the background required to correctly and easily use security protocols required to build modern applications. I am writing the book I wish I had when I started learning security as a developer. This book is focused on security use cases you need to implement in applications. By the end of the book, you will know how to: Use industry standard cryptography algorithms correctly Implement Single Sign On using OpenID Connect Get rid of passwords using the Web Authentication Protocol Configure and debug mutual TLS connections easily and correctly Store and access application secrets in the most popular key management services. Securely containerize your application and then Lockdown it down tight on Kubernetes Use API gateways and service mesh to secure the service-to-service call chain I assume you are a developer who can read Java code, but don’t have a deep security background. The book provides you with all the required background
Page 5
and concepts you need. For each concept you will have a working application that you run, put break points on, and study so that you can learn what you need to learn. To make the dry topics of cryptography easier to comprehend I have built sample applications using libraries and standards you are likely to encounter. Please be patient and work your way through the book chapter by chapter, so you don’t get lost by skipping ahead and then finding that you are missing some background. If you go through the book chapter by chapter and run the sample apps, everything will make sense. Please be sure to post any questions, comments, or suggestions you have about the book in the liveBook discussion forum. —Adib Saikali In this book welcome Part 1 Application Security the Big Picture 1 Making Sense of Application Security 2 Standards for implementing authentication 3 Service- to-service communication Part 2 Cryptography Foundations 4 Message Integrity and Authentication 5 Advanced Encryption Standard 6 JSON Object Signing and Encryption (JOSE) 7 Public Key Encryption and Digital Signatures: Unleashing RSA 8 Public Key Encryption and Digital Signatures: Using ECC 9 Public Key Infrastructure and X.509 Digital Certificates: know who you are talking to 10 Working with X.509 Certificates: Lifecycle and Self-Signing 11 Transport Layer Security (TLS): How the internet is secured 12 Single Sign On (SSO) using OAuth2 and OpenID Connect 13 Deepening security with OpenID Connect 14 Passwordless login: Using Magic links and OTPs 15 Passwordless login: WebAuthn and hardware authentication
Page 6
Part 1 Application Security the Big Picture Computer security is a vast field with many different technologies that must be learned independently then combined correctly in an application. Application developers and architects typically learn security technologies on the job when they first encounter them while under pressure to deliver product features and bug fixes. Reading blog posts, cutting and pasting configuration settings, and searching stackoverflow.com for help while under pressure to deliver leaves developers feeling like they don’t understand security but also don’t have the time and resources to properly learn it. A step-by-step plan that breaks security technologies into easily digestible chunks that a developer or architect can learn quickly and independently on the job is the goal of part 1. The plan starts by building a mental model of cloud native application security. The model allows you to definitely answer the following questions. What security technologies do you need to know to implement security on the application you are currently working on? What is the correct order to learn security technologies in so that you don’t get stuck because you don’t understand a dependency of the technology you are learning? What level of depth should you aim for when learning a security technology? What is the division of roles and responsibilities between application developers, architects, cloud automation engineers, infrastructure providers, and security engineers? We will take a top-down approach to security starting with how to secure a single monolithic application, then a collection of microservices. Part 1 will help you grasp the big picture, connect the dots between the security standards and technologies widely used for cloud native applications, enabling you to zoom in on the relevant parts of the book for your needs.
Page 7
1 Making Sense of Application Security This chapter covers What DevSecOps is and why is it essential Identifying how security roles & responsibilities are divided up between developers and everyone else in an organization implementing DevSecOps Identifying the security skills you should possess as an application developer Every week we are treated to a headline about some security vulnerability in a widely used piece of software or a data breach at a mega-corporation affecting millions of users (figure 1.1). My bank replaced my credit card twice in a five-year period due to data breaches at large retailers where I shopped. Figure 1.1 Headlines showcasing major recent data breaches and security vulnerabilities, emphasizing the widespread impact on millions of users and the persistent threat to digital security.
Page 8
We used to think that security vulnerabilities are primarily a software issue. However, hardware security vulnerabilities have been common in recent years. Specter and Meltdown[1] reported in January 2018 allowed attackers to bypass the CPU hardware protection for memory access. In a cloud or multi-tenant environment, specter and meltdown make it possible for one
Page 9
cloud tenant to see the memory of another tenant. The hardware walls we depend on to isolate workloads were suddenly full of holes for attackers to sneak through. The past few years have taught us that every layer of the stack, from hardware all the way to JavaScript in a web browser, can have security vulnerabilities. Security is everyone's collective responsibility to build and run IT systems, from hardware engineers who design the processors in our phones to application developers who build the e-commerce applications that keep our kitchens stocked with food. Regardless of your role in the IT world, security is your responsibility. MINDSET Regardless of your role in the IT world security is your responsibility. 1.1 Security as a CEO-level problem The average cost of a data breach in 2020 is $3.92 million[2]. Some mega breaches, such as Marriot Hotels leaked 500 million[3] customer records. Marriott took a $126 million charge to deal with the data breach. Equifax an American credit reporting agency spent 1.4 billion[4] dollars on cleanup costs associated with the 2017 data breach of 150 million personal credit histories. A significant security incident has the potential to be a company ending event. CEOs are quite concerned about the business impact of security breaches, so they appoint a Chief Information Security Officer (CISO) reporting directly to them as a peer of the Chief Information Officer (CIO). Reporting directly to the CEO enables the CISO to make the necessary organizational and technology changes to secure corporate IT systems. The heightened focus on security by senior business leaders affects application developers in the following ways: Use all product security features: CISOs expect developers to use every security feature available in products to secure an application. Do you know how to configure and use the security features in the application
Page 10
server, database, object store, message broker, API gateway, service mesh, cloud services, programming language, and development frameworks being used on a project you are working on? It is no longer enough to know how to use a product, you must know how to use it securely. Follow corporate security standards: CISOs expect applications to pass strict corporate security assessments and audits. As a developer, you must explain to assessors and auditors how your application meets corporate security standards. This means you need to be able to speak the security language used by information security professionals so you can avoid costly remediation work to fix security issues late in the development cycle. Design and implement secure applications: CISOs expect architects and developers to design and implement secure applications. This means that you must be familiar with many security protocols and technologies required to design and implement secure applications. Enable DevSecOps Transformation: CISOs are investing heavily in breaking down the silos between the development, operations, and security teams. This means that as a developer you need to become familiar with new tools, processes, and practices used to implement DevSecOps. A search for the term “computer security” in the amazon.com books section yielded 40,000 results. It is easy to get lost in the details when learning computer security. Figure 1.2 provides a map of the broad areas of application security. Figure 1.2 Layers at the top depend on the layers below them. All the layers are required to produce secure application. The standards, protocols, and patterns used to secure applications are the primary focus of this book, they are the foundation that you need to use security libraries in your application effectively.
Page 11
The top of the diagram above represents the goals of senior business leaders to build secure applications that can stand up to attacks. The higher layers of the diagram depend on the layers below them. To secure an application, you need to use security libraries; for example, a Java web application might use Spring Security to authorize user access. Security libraries are not enough to provide security. You must design, code, and maintain the application in a secure way by following the corporate security practices for application development, for example, performing a security code review or setting code analyzers that detect common security
Page 12
coding mistakes. As a developer, you spend your time in the middle layer of the pyramid above. Security libraries and frameworks provide implementations of industry- standard protocols and patterns in specific programming languages. For instance, the Java Standard Libraries include support for Transport Layer Security (TLS), which we’ll explore in chapter 11, while Spring Security offers robust support for OpenID Connect (OIDC), discussed in chapters 12 and 13. Developers often invest significant effort into mastering these security libraries, which are critical to building secure applications. However, many developers find these libraries challenging to learn and cumbersome to use effectively. The root cause of developer difficulties using security libraries is a lack of knowledge about the underlying standards, protocols, and patterns the libraries implement. If you understand the underlying security standards, protocols, and best practices, you will find security libraries and frameworks much easier to learn and use. For example, if you understand the OpenID Connect standard, you will find configuring Single Sign On authentication with Spring Security easy to configure and debug. TIP If you are familiar with the standards, protocols, and patterns, using security libraries and frameworks becomes much easier. Investing time to understand these underlying principles will significantly enhance your ability to work effectively with security tools. This book focuses on teaching you the standards, protocols, and patterns implemented by the majority of application security libraries and frameworks through understanding the use case sample applications. The sample applications are implemented in Java using open-source frameworks such as Spring Security, Nimbus, Google Tink, and others. So long as you can read Java code, you can learn about security standards, protocols, and patterns. For Java developers, the book will give you a head start with these commonly used frameworks so you can more easily deep dive into the specific features that interest you using the framework's online
Page 13
documentation. Every company follows a Software Development Life Cycle (SDLC) process for building applications. In mature companies, the SDLC includes a set of security processes and practices that developers are expected to follow in order to ensure that applications are secure. Companies build their SDLCs by customizing industry best practices to meet their needs. For example, an SDLC might be based on an agile process such as Scrum with security practices such added such as: Automated tooling to scan for security vulnerabilities in application code (such as Snyk) Security design review at the start of each sprint Security code review at the end of each sprint (included in the definition of done) Developers must understand the problems various security processes and practices are designed to solve. Understanding the problems makes it easier to apply the practices and processes correctly. This book provides the background required to work well in a secure software development cycle, but it does not teach practices or processes. Check out the book “Secure By Design” (Manning, 2019) by Dan Bergh Johnsson, Daniel Deogun, and Daniel Sawano if you want to learn more about how to design secure software. The first step in the learning journey is to build a big-picture mental model of application security use cases and the available solutions. In this chapter, we start the learning journey by analyzing two common security problems: Securing communication channels Securing application dependencies Examining how to secure communication channels and application dependencies enables us to make sense of the types of skills an application developer needs to know about security and map out a practical approach for learning security skills. In the next two chapters, we will analyze a common set of security problems
Page 14
encountered when building monolithic and microservice-based applications so that you can understand the security technologies and standards that every developer should be familiar with to build secure modern applications and systems. Put on your boots and grab a strong coffee; we are about to explore the security mountain; it will take some effort, but we have made the trail as clear as possible, with good rest stops on the climb up the mountain. I promise you that the view from the top of the mountain is breathtaking and worth the sweat and effort you will put in. 1.2 Securing communication channels Consider ACME Inc. a shoe retailer with 1000 physical stores in 5 countries and an online shopping application that customers use to buy shoes from anywhere in the world. Customers can shop for shoes on ACME’s website or native mobile apps. ACME’s application architecture is typical for large enterprise applications. The frontend user interface consists of three separate applications: an HTML5-based web app, a Kotlin-based Android app, and a Swift-based iOS app. The backend exposes a REST API over HTTP using JSON as the data exchange format (figure 1.3). The backend is a large application (1,000,000+ lines of code) running on an application server that processes the HTTP requests and stores the state in an SQL database. Figure 1.3 The high-level architecture of the ACME Inc. shopping applications. Three shopping applications: browser, iPhone, and Android, communicate with a monolithic backend using an HTTP JSON based REST API.
Page 15
When data is transmitted between a user’s device and the application backend, it travels across several untrusted networks, such as the public Wi- Fi in a coffee shop where the user might enjoy a coffee while using the application on her mobile phone. These untrusted networks allow hackers to intercept and steal data while it is in transit. All communication between the application’s front-end user interfaces and the backend must be encrypted using the industry-standard Transport Layer Security (TLS) protocol to
Page 16
protect sensitive information. The application backend, however, accesses its database over a private data center network. Extensive access controls and defense mechanisms protect these networks. Network engineers typically segment corporate networks into zones separated by firewalls and other security devices. For example, load balancers handling traffic from the internet are placed in an untrusted "red zone," application servers are placed in a more controlled "yellow zone," and database servers reside in a highly secure "green zone." Figure 1.4 provides a visual representation of this architecture. Josh is taking his coffee while surfing the Acme. Inc. online shop over a public network. Figure 1.4 An example of network segmentation involves dividing the infrastructure into distinct zones based on trust levels. The red zone hosts publicly accessible servers, such as load balancers. The yellow zone is designated for application servers; it is not directly accessible from the internet but can communicate with the red zone. The green zone is reserved for data services, which are only accessible from the yellow zone. Even in a highly segmented and zoned network, it is a best practice to use TLS to encrypt all application communication paths, ensuring data security throughout the system.
Page 17
It is tempting to assume there is no need to encrypt communications between the application backend and its database because the traffic is on a “trusted” internal network. Resist the temptation to trust the data center network for the following reasons. Configuration errors: security configuration errors on the network are possible, especially in large corporate networks with hundreds and thousands of applications. Disgruntled insider: a company insider with legitimate network access might choose to attack the application. Compromised application: The “internal” corporate network has many applications on it; some are internal applications built by the enterprise,
Page 18
and some are Commercial On-The-Shelf (COTS) applications purchased from various vendors. If a single application on the internal network is compromised, then the whole network is compromised. For example, Target[5] a large American retailer suffered a data breach of its point-of-sale system (POS) that affected 41 million consumers and cost $18.5 million in fines. Hacker breached[6] Target’s POS by gaining access to the network with the credentials used to maintain the air conditioning system in Target stores. It is a best practice to operate under the zero-trust networking model, where you assume the network is always untrusted. Treat the internal data center network with the same level of suspicion that you treat the internet. As an application developer, you must insist on TLS everywhere for any application network communications. Getting comfortable with the TLS protocol is a critical security skill for developers. Mastering TLS enables you to: Write secure applications that meet corporate security standards. Quickly configure TLS in your code without spending hours searching blogs or using AI tools for setup instructions. Debug connectivity issues caused by TLS configuration settings easily. TLS is a large, complex protocol; whole books have been written about it. This book will demystify TLS in chapter 11. We will cover this subject from the point of view of an application developer. We don’t assume you have any previous experience with TLS or cryptography so we will build all the foundational computer security concepts required to fully understand TLS. To understand TLS, you will need to understand the following security building blocks. Cryptographic Hash Functions Message Authentication Code (MAC) Hashed Message Authentication Code (HMAC) Advanced Encryption Standard (AES) Block encryption operating models Authenticated encryption
Page 19
RSA public key cryptosystem Elliptic curve public key cryptosystem Diffie-Helman key exchange X.509 digital certificates Certificate authorities and public key infrastructure There is a tangled web of algorithms based on deep, beautiful mathematics at the heart of TLS. You do not need to understand how these algorithms work or the math behind them, but you must understand what they do and how to configure them correctly in your applications. We will use sample applications to explore the security building blocks to keep the book developer-focused. We will present sample applications written in Java using popular open-source Java libraries such as Spring, Google Tink, Nimbus, and others. Running these applications will teach you what the security algorithms do and expose you to the various configuration options. The code is written to demonstrate key security concepts. You can run the code and learn the application security concepts even if you are not a Java developer. Mastering TLS is a critical skill for an application developer. If you take the time to go through parts 2 & 3 of the book and run the sample applications, we promise that you will learn enough about TLS that you will never again get stuck debugging a TLS issue. You will always know what to look for to resolve the issue. Parts 2 & 3 are organized in a step-by-step manner, with each section building on top of the previous one, so we recommend you read it in the order it is presented. BEST PRACTICE Place zero-trust in all networks including internal “secure” networks. Use TLS everywhere for all application communication channels with everyone and everything. Roles and Responsibilities Three organizational roles are involved in securing communication channels:
Page 20
security engineers network engineers developers Security engineers provide guidance on how to secure applications and networks. The guidance is typically published as a collection of corporate information security documents laying out the required configuration of TLS, network segmentations, and numerous other security-related requirements. Security engineers perform audits and assessments of all levels of the IT stack to ensure compliance with corporate standards. Network engineers own the setup and management of the corporate networks in accordance with the guidance provided by the security engineers. Developers own writing code that follows the guidance provided by security engineers, which means configuring TLS clients and servers only using approved configurations. Developers provide network engineers with connectivity requirements so that they can configure the network to enable communication most securely between an application and its collaborators. As a developer, mastering TLS makes you a better partner to the security and network engineers. 1.3 Securing application dependencies Applications are built on top of hundreds of open-source libraries and propriety software components. For example, today I am working on a Spring Boot application that depends on 106 open-source third-party libraries. I have seen some enterprise applications with 250+ library dependencies. Reusing software components across applications is a huge time and cost saver. However, it also introduces the possibility of catastrophic security failures. In 2017, the American credit reporting agency Equifax was hacked, exposing the credit histories of 150 million American citizens. As of May 2019, Equifax has spent over 1.4 billion[7] dollars on cleanup costs. The hack was caused[8] by a known vulnerability (CVE-2017-5638) in the Apache Struts library that Equifax failed to patch even though the vulnerability was known
The above is a preview of the first 20 pages. Register to read the complete e-book.

Recommended for You

Loading recommended books...
Failed to load, please try again later

Tip the Site

Scan the WeChat Pay or Alipay code to tip. No login required.

WeChat Pay
Alipay
← Back to List