API安全设计：OAuth 2.0框架下的保护机制

5星 · 超过95%的资源需积分: 10 44 浏览量更新于2024-07-19 1 收藏 4.99MB PDF 举报

"高级API安全：使用OAuth 2.0保护API" 在当今企业安全中，API安全是一项主要挑战。随着API的普及，保护公共和私有API变得越来越重要。OAuth 2.0框架是保护API的重要工具，本节将详细介绍OAuth 2.0框架及相关衍生协议。在API设计中，安全性是一个关键因素。随着API的普及，保护API变得越来越重要。OAuth 2.0框架提供了一种保护API的方式，它可以保护API免受未经授权的访问。 OAuth 2.0是一个 Industry-standard 认证和授权协议，提供了客户端和资源服务器之间的安全认证机制。OAuth 2.0框架包括四个主要组件：客户端、资源服务器、授权服务器和资源拥有者。 OAuth 2.0框架的主要特点是，它可以提供基于令牌的认证机制，客户端可以使用令牌来访问资源服务器。OAuth 2.0框架还提供了多种授权类型，例如授权码授权、隐式授权和客户端凭证授权。在OAuth 2.0框架中，还有多种协议衍生出来，例如OAuth 2.0 MACToken Profile、OAuth 2.0 Profiles等。这些协议提供了更多的安全功能，例如身份委托、联合身份验证等。对于API的安全性，OAuth 2.0框架提供了一种保护API的方式。OAuth 2.0框架可以保护API免受未经授权的访问，保护API的敏感信息。在API设计中，安全性是一个关键因素。OAuth 2.0框架提供了一种保护API的方式，保护API免受未经授权的访问。同时，OAuth 2.0框架还提供了多种协议衍生出来，例如OAuth 2.0 MACToken Profile、OAuth 2.0 Profiles等，提供了更多的安全功能。 OAuth 2.0框架是保护API的一种重要工具。它提供了一种基于令牌的认证机制，客户端可以使用令牌来访问资源服务器。OAuth 2.0框架还提供了多种授权类型和协议衍生出来，提供了更多的安全功能。知识点： * OAuth 2.0框架是保护API的一种重要工具 * OAuth 2.0框架提供了一种基于令牌的认证机制 * OAuth 2.0框架包括四个主要组件：客户端、资源服务器、授权服务器和资源拥有者 * OAuth 2.0框架提供了多种授权类型，例如授权码授权、隐式授权和客户端凭证授权 * OAuth 2.0框架还提供了多种协议衍生出来，例如OAuth 2.0 MACToken Profile、OAuth 2.0 Profiles等 * OAuth 2.0框架可以保护API免受未经授权的访问 * OAuth 2.0框架提供了一种保护API的方式，保护API的敏感信息

CHAPTER 2 ■ SECURITY BY DESIGN

period of the key and, if it has expired, make another call to the authorization server to generate a new key. If you

make the lifetime too short, then for each API call, there will be another call to the authorization server to generate a

new key. That kills performance—but drastically reduces the impact of an intruder getting access to the API key.

Weakest Link

A proper security design should include all the communication links in the system. Your system is no stronger than its

weakest link. In 2010, it was discovered that since 2006, a gang of robbers equipped with a powerful vacuum cleaner

had stolen more than 600,000 euros from the Monoprix supermarket chain in France. The most interesting thing was

the way they did it. They found out the weakest link in the system and attacked it. To transfer money directly into the

store’s cash coffers, cashiers slid tubes filled with money through pneumatic suction pipes. The robbers realized that it

was sufficient to drill a hole in the pipe near the trunk and then connect a vacuum cleaner to capture the money. They

didn’t have to deal with the coffer shield.

Defense in Depth

A layered approach is preferred for any system being tightened for security. This is also known as defense in depth.

Most international airports, which are at a high risk of terrorist attacks, follow a layered approach in their security

design. On November 1, 2013, a man dressed in black walked into the Los Angeles International Airport, pulled

a semi-automatic rifle out of his bag, and shot his way through a security checkpoint, killing a TSA screener and

wounding at least two other officers. This was the first layer of defense. In case someone got through it, there has to be

another to prevent the gunman from entering a flight and taking control. If there had been a security layer before the

TSA, maybe just to scan everyone who entered the airport, it would have detected the weapon and probably saved the

life of the TSA officer.

The number of layers and the strength of each layer depend on which assets you want to protect and the threat

level associated with them. Why would someone hire a security officer and also use a burglar alarm system to secure

an empty garage?

Insider Attacks

Insider attacks are less powerful and less complicated, but highly effective. From the confidential US diplomatic

cables leaked by WikiLeaks to Edward Snowden’s disclosure about the National Security Agency’s secret operations,

are all insider attacks. Both Snowden and Bradley Manning were insiders who had legitimate access to the

information they disclosed. Most organizations spend the majority of their security budget to protect their systems

from external intruders; but approximately 60% to 80% of network misuse incidents originate from inside the network,

according to the Computer Security Institute (CSI) in San Francisco.

Note ■ Insider attacks are identified as a growing threat in the military. To address this concern, the US Defense

Advanced Research Projects Agency (DARPA) launched a project called Cyber Insider Threat (CINDER) in 2010. The

objective of this project was to develop new ways to identify and mitigate insider threats as soon as possible.

www.it-ebooks.info

CHAPTER 2 ■ SECURITY BY DESIGN

Security by Obscurity

Kerckhoffs Principle

emphasizes that a system should be secured by its design, not because the design is unknown

to an adversary. Microsoft’s NTLM design was kept secret for some time, but at the point (to support interoperability

between Unix and Windows) Samba engineers reverse-engineered it, they discovered security vulnerabilities caused

by the protocol design itself. In a proper security design, it’s highly recommended not to use any custom-developed

algorithms or protocols. Standards are like design patterns: they’ve been discussed, designed, and tested in an open

forum. Every time you have to deviate from a standard, should think twice—or more.

Design Principles

Jerome Saltzer and Michael Schroeder produced one of the most widely cited research papers in the information

security domain.

The paper, “The Protection of Information in Computer Systems,” put forth eight design principles

for securing information in computer systems, as described in the following sections.

Least Privilege

The principle of least privilege states that an entity should only have the required set of permissions to perform the

actions for which they are authorized, and no more. Permissions can be added as needed and should be revoked

when no longer in use. This limits the damage that can result from an accident or error.

Note ■ The need to know principle is popular in military security. This states that even if someone has all the necessary

security clearance levels to access information, they should not be granted access unless there is a real/proven need.

Fail-Safe Defaults

This principle highlights the importance of making a system safe by default. A user’s default access level to any

resource in the system should be “denied” unless they’ve been granted a “permit” explicitly. The Java Security

Manager implementation follows this principle—once engaged, none of the components in the system can perform

any privileged operations unless explicitly permitted.

Economy of Mechanism

This principle highlights the value of simplicity. The design should be as simple as possible. All the component

interfaces and the interactions between them should be simple enough to understand.

In 1883, Auguste Kerckhoffs published two journal articles on La Cryptographie Militaire in which he emphasized six design

principles for military ciphers. This resulted in the well-known Kerckhoffs’ Principle: A cryptosystem should be secured even if

everything about the system, except the key, is public knowledge.

“The Protection of Information in Computer Systems,” http://web.mit.edu/Saltzer/www/publications/protection/,

October 11, 1974.

www.it-ebooks.info

CHAPTER 2 ■ SECURITY BY DESIGN

Complete Mediation

With complete mediation, a system should validate access rights to all its resources to ensure that they’re allowed.

Most systems do this once at the entry point to build a cached permission matrix. Each subsequent operation

validates the resource permission against the permission matrix. If the access level to a given resource is being

revoked, but that isn’t reflected in the permission matrix, it would violate this principle.

Open Design

This principle highlights the importance of building a system in an open manner—with no secret, confidential

algorithms. This is the opposite of security by obscurity, discussed earlier in the section “Design Challenges.”

Separation of Privilege

The principle of separation of privilege states that granting permissions to an entity should not be purely based on

a single condition. For example, say a reimbursement claim can be submitted by any employee but can only be

approved by the manager. What if the manager wants to submit a reimbursement? According to this principle, the

manager should not be granted the right to approve his or her own reimbursement claims.

Least Common Mechanism

The principle of least common mechanism concerns the risk of sharing state among different components. If one can

corrupt the shared state, it can then corrupt all the other components that depend on it.

Psychological Acceptability

The principle of psychological acceptability states that security mechanisms should not make the resource more

difficult to access than if the security mechanisms were not present. Microsoft introduced Information Cards in 2006

as a new paradigm for authentication to fight against phishing. But the user experience was bad, with a high setup

cost, for people who were addicted to username/password-based authentication. It went down in history as another

unsuccessful initiative from Microsoft.

Confidentiality, Integrity, Availability (CIA)

Confidentiality, integrity, and availability are three key factors used in benchmarking information systems security, as

discussed next.

Confidentiality

Confidentiality means protecting data from unintended recipients, both at rest and in transit. You achieve

confidentiality by protecting transport channels and storage with encryption. For APIs, where the transport channel is

HTTP, you can use Transport Level Security (TLS), which is HTTPS. For storage, you can use disk-level encryption or

application-level encryption. Channel encryption or transport-level encryption isn’t 100% secure. In contrast, there is

message-level encryption, which happens at the application level and has no dependency on the transport channel.

If you secure data with message-level encryption, then you can use HTTP as the transport channel. Transport-level

www.it-ebooks.info

CHAPTER 2 ■ SECURITY BY DESIGN

encryption only provides point-to-point protection and truncates from where the connection ends. As soon as data

leaves the transport channel, it’s no longer secured. At the same time, when you connect to an API gateway through a

proxy, the data could be in cleartext while inside the proxy.

A TLS connection from the client to the gateway can be established in two ways: either with SSL bridging or

with SSL tunneling. Almost all proxy servers support both modes. For a highly secured deployment, SSL tunneling

is recommended. In SSL bridging (see Figure 2-1), the initial connection truncates from the proxy server, and a new

connection to the gateway is established from there. That means the data is in cleartext in the proxy server. Any

intruder who can plant malware in the proxy server can intercept traffic that passes through. With SSL tunneling

(see Figure 2-2), the proxy server facilitates creating a direct channel between the client machine and the gateway.

The data flow through this channel is invisible to the proxy server.

Client

Application

HTTP Proxy

TLS Negotiation

TLS Traffic

API Gateway

Figure 2-1. SSL bridging

Note ■ Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably, but in pure

technical terms they aren’t the same. TLS is the successor of SSL 3.0. TLS 1.0, which is defined under the IETF RFC

2246, is based on the SSL 3.0 protocol specification, which was published by Netscape. The differences between TLS 1.0

and SSL 3.0 aren’t dramatic, but they’re significant enough that TLS 1.0 and SSL 3.0 don’t interoperate.

Message-level encryption, on the other hand, is independent from the underlying transport. It’s the

application developers’ responsibility to encrypt and decrypt messages. Because this is application specific, it hurts

interoperability and builds tight couplings between the sender and the receiver. Each has to know how to encrypt/

decrypt data beforehand—which will not scale up in a distributed system. To overcome this challenge, there have

been some concentrated efforts to build standards around message-level encryption. XML Encryption is one such

effort, led by the W3C. It standardizes how to encrypt an XML payload. Similarly, the IETF JavaScript Object Signing

and Encryption (JOSE) working group is in the process of building a set of standards for JSON payloads. JSON Web

Encryption and JSON Web Signature are discussed in Chapter 13.

Client

Application

HTTP Proxy

HTTP CONNECT

TCP Connection Established

TSL Negotiation and TLS Traffic

Connection Established

API Gateway

Figure 2-2. SSL tunneling

www.it-ebooks.info

CHAPTER 2 ■ SECURITY BY DESIGN

Transport-level security encrypts the entire message. Because it relies on the underlying channel for protection,

application developers have no control over which part of the data to encrypt and which part not to. Partial encryption

isn’t supported by transport-level security, but it is supported by message-level security. The Table 2-1 summarizes

the key differences between transport-level security and message-level security.

Table 2-1. Transport-Level Security vs. Message-Level Security

Transport-Level Security Message-Level Security

Relies on the underlying transport No dependency on the underlying transport

Point-to-point End-to-end

Partial encryption not supported Partial encryption supported

High performance Relatively less performance

Integrity

Integrity is a guarantee of data’s correctness and trustworthiness and the ability to detect any unauthorized

modifications. It ensures that data is protected from unauthorized or unintentional alteration, modification, or

deletion. The way to achieve integrity is twofold: preventive measures and detective measures. Both measures have to

take care of data in transit as well as data at rest.

To prevent data from alteration while in transit, you should use a confidential channel that only intended parties

can read. TLS is the recommended approach for transport-level encryption. TLS itself has a way of detecting data

modifications. It sends a message-authentication code in each message from the initial handshake, which can be

verified by the receiving party to make sure the data has not been modified while in transit. For data at rest, you can

calculate the message digest periodically and keep it in a secured place. The audit logs, which can be altered by an

intruder to hide suspicious activities, need to be protected for integrity.

Note ■ HTTP Digest Authentication with the quality of protection (qop) value set to auth-int can be used to protect

messages for integrity. Chapter 3 discusses HTTP Digest Authentication in depth.

Availability

Making a system available for legitimate users to access all the time is the ultimate goal of any system design. Security

isn’t the only aspect to look into, but it plays a major role in keeping the system up and running. The goal of the

security design should be to make the system highly available by protecting it from illegal access attempts. Doing so is

extremely challenging. Attacks, especially on a public API, can vary from an attacker planting malware in the system to

a highly organized distributed denial of service (DDoS) attack.

DDoS attacks are hard to eliminate fully, but with a careful design they can be minimized to reduce their impact.

In most cases, DDoS attacks must be detected at the network perimeter level—so, the application code doesn’t need

to worry too much. But vulnerabilities in the application code can be exploited to bring a system down. The research

paper “A New Approach towards DoS Penetration Testing on Web Services” by Christian Mainka, Juraj Somorovsky,

Jorg Schwenk, and Andreas Falkenberg (https://www.nds.rub.de/media/nds/veroeffentlichungen/2013/07/19/

ICWS_DoS.pdf) discusses eight types of DoS attacks that can be carried out against SOAP based APIs with XML

payloads:

www.it-ebooks.info

剩余247页未读，继续阅读

poyuzhe1

粉丝: 0
资源: 1

API安全设计：OAuth 2.0框架下的保护机制

spring boot restful服务小例子

Advanced API Security

Networkers2009：BRKSEC-3003 - Advanced IPv6 Security: Securing Link-Operations at First Hop

思科PPT：Securing Web Applications

PS-Securing-Your-Application-with-OAuth-and-Passport:Oauth使用OAuth和Passport保护您的应用程序安全

NXP SECURE PLATFORM: SECURING THE PRODUCT LIFE CYCLE

Flex on Java book excerpt: Securing your Flex application

CRC Press： Securing and Controlling Cisco Routers.pdf

Wiley Press: Securing Wireless LANs-A Practical Guide for Network Managers LAN Administrators and the Home Office User.pdf

Api-securing-restful-apis-with-jwt.zip

最新资源