Date post: | 06-Apr-2018 |
Category: |
Documents |
Upload: | minal-patil |
View: | 216 times |
Download: | 0 times |
of 121
8/3/2019 0572.AzureSecurityNotes
1/121
Azure SecurityNotesLessons Learned from
Exploring Microsoft Azure and the Cloud Security Space
J.D. Meier, Principal PM, MicrosoftPaul Enfield
8/3/2019 0572.AzureSecurityNotes
2/121
Acknowledgments
Thanks to the following external contributors and reviewers:
Adam Grocholski; Andy Eunson; Bill Collette; Christopher Seary; Jason Taylor; John Daniels;
Juval Lowy; Kevin Lam; Long Le; Michael Smith; Michael Stiefel; Michele Leroux Bustamante;
Norman Headlam; Rockford Lhotka; Rudolph Araujo; Sarang Kulkarni; Steven Nagy; Terrance
Snyder; Will Clevenger
Thanks to the following Microsoft contributors and reviewers:
Akshay Aggarwal; Alik Levin; Andreas Fuchsberger; Babur Butter; Bharat Shyam; Dave Brankin;
Danny Cohen; Diego Dagum; Don Willits; Eugenio Pace; Gabriel Morgan; Jeff Mueller; John
Steer; Julian Gonzalez; Mark Curphey; Mohit Srivastava; Pat Filoteo; Rahul Verma; Raul Rojas;
Scott Densmore; Sesha Mani; Serena Yeoh; Sriram Krishnan; Stefan Schackow; Steve Marx;
Stuart Kwan; Terri Schmidt; Tobin Titus; Varun Sharma; Vidya Vrat Agarwal; Vikram Bhambri;
Yale Li
8/3/2019 0572.AzureSecurityNotes
3/121
Our Cloud Security Approach
Objectives Learn a security frame Learn an approach for applying the security frame to application scenarios Learn key components of the security approach for these notes
OverviewThese notes summarize how we took a look at securing Web applications, web services, and
data in the cloud. We basically started by mapping out common application scenarios. We
then figured out a way to group threats and attacks into a set of common categories. These
categories make it easy for us to analyze and inspect the various parts of an application andengineering decisions. Then we focused on finding common principles, patterns, and practices,
while working with customers, field, product teams, and industry experts.
Our Cloud Security Approach in a NutshellWe took a pragmatic approach to security, identifying key deltas, building on what we know,
and leveraging proven practices. Here are some of the cornerstone concepts we used to focus
and drive our security efforts:
Visual Application Scenarios and Solutions. We created simple visuals that show end-to-end scenarios. You can think of these as how you might put on a whiteboard if you were to
draw the end in mind for a particular application scenario. This is a simple way to share
authentication and authorization patterns for common application scenarios.
Secure the network, host, and application. Ask any security expert, where the problemsare, and theyll say its the stuff that falls between the cracks. Thinking about security
holistically across the network, host, and application is the key to both helping you focus
your efforts, as well as catching what falls between the cracks.
Principles, patterns, and practices. Design principles help you leverage proven practices.Rather than have a rule for everything, you have a smaller set of principles to guide you.
Patterns are simply problem and solution pairs in context. They help share strategies and
principles by building a shared vocabulary. For example, the Trusted Subsystem pattern
http://msdn.microsoft.com/en-us/library/ff649178.aspxencapsulates the idea of trusting
the application identity rather than every caller. Practices are simply actions, methods, ortechniques. For example, you can use patterns & practices Threat Modeling
http://msdn.microsoft.com/en-us/library/ff648006.aspxto shape the security design of
your application.
Threats and countermeasures. One way to make security actionable and prescriptive is tofocus on threats and countermeasures. This means identifying the bad things that can
happen, and what your defenses, security controls, or countermeasures are.
http://msdn.microsoft.com/en-us/library/ff649178.aspxhttp://msdn.microsoft.com/en-us/library/ff649178.aspxhttp://msdn.microsoft.com/en-us/library/ff648006.aspxhttp://msdn.microsoft.com/en-us/library/ff648006.aspxhttp://msdn.microsoft.com/en-us/library/ff648006.aspxhttp://msdn.microsoft.com/en-us/library/ff649178.aspx8/3/2019 0572.AzureSecurityNotes
4/121
Security Frame. There are many ways to chunk up and think about security. For example,you might use C.I.A., where C is confidentiality, I is integrity, and A represent availability.
Another approach is to focus on the three As: Authentication, Access control, and Auditing.
Weve found it especially useful to use the following categories to organize and share
application security principles, patterns, anti-patterns, and practices: Auditing and
Logging, Authentication, Authorization, Communication, ConfigurationManagement, Cryptography, Exception Management, Sensitive Data, Session
Management, and Validation.
People, process, and technology. Another way to look at security is through the people,process, and technology viewpoints. You can also use each of these views when you look
at security for your network, host, and application.
Application, Infrastructure, and Business. This is another helpful lens for looking atsecurity. You can look at the principles, patterns, and practices for the application, the
infrastructure, or the business. This leads to application security patterns, infrastructure
security patterns, and business security patterns and practices.
At the end of the day, whats important is using the lens that helps you the most, and avoid
using the wrong tool for the job, or using a one-size fits all solution. Instead, chunk up the
problem, while keeping a holistic view.
How We Got StartedTackling cloud security can be overwhelming without an approach. In these notes, we have an
approach that simplifies and improves security. It does so by chunking up security in a way that
helps us leverage proven practices, while sharing information around emerging practices.
One way to simplify thinking about security is to simplify the language. When we first started
talking with customers about the cloud and security, it was difficult to have meaningful
conversations, simply because we didnt have a shared vocabulary.
Using a threats and countermeasures approach to talk about security is a key step to simplifying
cloud security. Basically, we can look through our security lens (our security frame), and look
for threats, attacks, vulnerabilities, and countermeasures. We can use that same lens and look
for principles, patterns, and anti-patterns. This helps us turn security information into insight
and action.
Another important step is leveraging application types from the patterns & practices
Application Architecture Guide, second edition -http://msdn.microsoft.com/en-us/library/ff650706.aspx. Rather than focus on queues and worker roles, we can shift our
focus to application scenarios, and represent them visually. Our goal is to show how to secure
your Web application, Web services, and data in the cloud visually. With these scenarios we
can move to the whiteboard and draw end-to-end scenarios.
http://msdn.microsoft.com/en-us/library/ff650706.aspxhttp://msdn.microsoft.com/en-us/library/ff650706.aspxhttp://msdn.microsoft.com/en-us/library/ff650706.aspxhttp://msdn.microsoft.com/en-us/library/ff650706.aspxhttp://msdn.microsoft.com/en-us/library/ff650706.aspxhttp://msdn.microsoft.com/en-us/library/ff650706.aspx8/3/2019 0572.AzureSecurityNotes
5/121
By using a security frame, focusing on threats and countermeasures, and visual scenarios, we
have an effective backdrop for analyzing, evaluating, and talking about cloud security
challenges.
Threats and Countermeasures FocusOne way to make security actionable and prescriptive is to focus on threats, attacks,
vulnerabilities and countermeasures:
Threat - A potential occurrence malicious or otherwise that may harm an asset. Attack - An action taken to harm an asset. Vulnerability - A weakness that makes a threat possible. Countermeasure - A safeguard that addresses a threat and mitigates risk.This means identifying the bad things that can happen, and what your defenses, security
controls, or countermeasures are. By building a knowledgebase of threats, attacks,
vulnerabilities, and countermeasures, we can dramatically improve our ability to share securityknow-how.
Example Application Scenario and SolutionEach Visual Scenario and Solution consists of a Scenario, Solution, and Solution Summary Table.
The Scenario is a simple visual of the application from a deployment standpoint. The Solution is
a visual of how you might address authentication, authorization, and communication (the
security runtime patterns.) The Solution Summary Table is a quick description of how you
would address the authentication, authorization, and communication from a security
standpoint.
Scenario
8/3/2019 0572.AzureSecurityNotes
6/121
Solution
Solution Summary Table
Area Notes
Authentication Authenticate users with forms authentication Store users in Azure Tables Use TableStorageMembershipProvider for membership APIs Authenticate application against Azure Storage with access key Map ASP.NET users to single Azure Storage connection All access to the database occurs as the application identity
Authorization Use TableStorageRoleProvider for roles APIs Authorize users in application logic Store roles in Azure Tables
Communication Use HTTP port 80 for non-secure connections to ASP.NET application Perform forms authentication over port 443 (SSL)
Security FrameA Security Frame acts as a simple lens. It helps organize and share security knowledge in a set
of actionable buckets. Here is an explanation of the key buckets used in these notes:
Category Notes
Auditing and Logging How security-related events are recorded, monitored, and audited.
Authentication The process of proving identity, typically through credentials, such as a user
name and password
Authorization How your application provides access controls for roles, resources and
operations.
Communication How data is transmitted over the wire. Transport security versus message
encryption is covered here.
Configuration
Management
How your application handles configuration and administration of your
applications from a security perspective.
Cryptography How your application enforces confidentiality and integrity.
Exception
Management
How you handle applications errors and exceptions.
Sensitive Data How your application handles any data that must be protected either in
8/3/2019 0572.AzureSecurityNotes
7/121
memory, over the network, or in persistent stores
Session Management A session refers to a series of related interactions between a user and your
application.
Validation How your application filters, scrubs, or rejects input before additional
processing, or how it sanitizes output.
The key to the buckets is that they are actionable. Another key is that developers can relate to
them. This makes it easier to share security knowledge between security experts and
developers in a pragmatic way.
Carrying the Story ForwardImproving Web Application Security: Threats and Countermeasures
(http://msdn.microsoft.com/en-us/library/ff649874.aspx) illustrates the approach of securing a
solution by addressing key security hotspots defined by the security frame in Figure 1 below.
This visual model allows you to conceptualize specific areas and items in an architecture that
need to be addressed during the process of securing an application. The visual model
represents a fairly typical on-premise application architecture, and then pins hotspots against
it.
Figure 1. Securing the Network, Host and Application On-premise
Using this visual model concept and the revised security frame for cloud applications we can
use the same approach to evaluate cloud applications. In Figure 2 below, we modify the visual
Database
Web
Server
Application
Server
Database
Server
Firewall Apps
Firewall Apps
Host Host
Patches and UpdatesServicesProtocols
AccountsFiles and DirectoriesShares
Securing the Host
Host
RouterFirewallSwitch
Securing the
Network PortsRegistryAuditing and Logging
Threats and Countermeasures
Exception ManagementParameter ManipulationSensitive DataSession ManagementValidation
Auditing and LoggingAuthenticationAuthorizationConfiguration Mgt.Cryptography
Securing the Application
http://msdn.microsoft.com/en-us/library/ff649874.aspxhttp://msdn.microsoft.com/en-us/library/ff649874.aspxhttp://msdn.microsoft.com/en-us/library/ff649874.aspxhttp://msdn.microsoft.com/en-us/library/ff649874.aspx8/3/2019 0572.AzureSecurityNotes
8/121
model by hosting both the application and data layers in the managed infrastructure, which in
this case is the cloud. With a managed infrastructure we can remove checks from our list
because they are items handled by the managed infrastructure. For example, a Windows Azure
application will not have permissions to create user accounts, or elevate privileges. This
alleviates the need to manage accounts at the host level.
Firew
all Apps
Cloud Host
Threats and Countermeasures
Data
ApplicationLayer
Managed
Infrastructure
DatabaseLayer
Patches and UpdatesServicesProtocols
AccountsFiles and DirectoriesShares
PortsRegistryAuditing and Logging
Securing the Host
CryptographyException ManagementSensitive DataSession ManagementValidation
Auditing and LoggingAuthenticationAuthorizationCommunication
Configuration Management
Securing the Application
RouterFirewallSwitch
Securing the
Network
Figure 2. Securing the Network, Host and Application in the Cloud
The above diagram represents the canonical case architecture. To evaluate other architectures
such as ones involving federated identity or hybrid on-premise and cloud implementations, you
can use the same approach. Represent your architecture with a base diagram, and overlay the
frame on it. Once the frame is overlaid, you can evaluate each item for applicability and quickly
scope out categories not needing attention.
8/3/2019 0572.AzureSecurityNotes
9/121
Cloud Security Threats and Countermeasures
Objectives Learn a security frame that applies to the cloud. Learn top threats/attacks, vulnerabilities and countermeasures for each area within the
security frame.
Understand differences between threats, attacks, vulnerabilities and countermeasures.
OverviewIt is important to think like an attacker when designing and implementing an application.
Putting yourself in the attackers mindset will make you more effective at designing mitigations
for vulnerabilities and coding defensively. This section is a reference of the security frame, andits pieces pinned against the cloud as a platform. We also present threats, vulnerabilities and
countermeasures against the cloud organized by hot spot such that you can see how they relate
to each other in each category.
Threats, Attacks, Vulnerabilities, and CountermeasuresThis chapter analyzes security from the perspectives of threats, vulnerabilities, attacks, and
countermeasures against the cloud. These terms are defined as follows:
Asset. A resource of value such as the data in a database, data on the file system, or asystem resource.
Threat. A potential occurrence malicious or otherwise that can harm an asset. Vulnerability. A weakness that makes a threat possible. Attack. An action taken to exploit vulnerability and realize a threat. Countermeasure. A safeguard that addresses a threat and mitigates risk.Cloud Security FrameThe following key security concepts provide a frame for thinking about security when designing
and architecting Windows Azure applications. Understanding these concepts helps you put core
security features such as authentication, authorization, auditing, confidentiality, integrity, and
availability in action.
Hot Spot Description
Auditing and
Logging
Auditing and logging in Windows Azure refers to how security-related events
are recorded, monitored, audited, exposed, compiled & partitioned across
multiple cloud instances. Examples include: Who did what and when and on
which VM instance?
Authentication Authentication is the process of proving identity, typically through credentials,
such as a user name and password. In the cloud this also encompasses
8/3/2019 0572.AzureSecurityNotes
10/121
authentication against varying identity stores.
Authorization Authorization in Windows Azure is how your application provides access
controls for roles, resources and operations. Authorization strategies might
involve standard mechanisms, utilize claims and potentially support a federated
model.
Communication Communication encompasses how data is transmitted over the wire. Transportsecurity, message encryption, and point to point communication are covered
here.
Configuration
Management
Configuration management refers to how your application handles
configuration and administration of your applications from a security
perspective. Examples include: Who does your application run as? Which
databases does it connect to? How is your application administered? How are
these settings secured?
Cryptography Cryptography in Windows Azure refers to how your application enforces
confidentiality and integrity. Examples include: How are you keeping secrets
(confidentiality)? How are you tamper-proofing your data or libraries
(integrity)? How are you providing seeds for random values that must be
cryptographically strong? Certificates and cert management are in this domain
as well.
Input and Data
Validation
Validation refers to how your application filters, scrubs, or rejects input before
additional processing, or how it sanitizes output. It's about constraining input
through entry points and encoding output through exit points. Message
validation refers to how you verify the message payload against schema, as well
as message size, content and character sets. Examples include: How do you
know that the input your application receives is valid and safe? Do you trust
data from sources such as databases and file shares?
Exception
Management
Exception management refers to how you handle applications errors and
exceptions. Examples include: When your application fails, what does your
application do? Does it support graceful failover to other application instancesin the cloud? How much information do you reveal? Do you return friendly
error information to end users? Do you pass valuable exception information
back to the caller?
Sensitive Data Sensitive data refers to how your application handles any data that must be
protected either in memory, over the network, or in persistent stores. Examples
include: How does your application handle sensitive data? How is sensitive data
shared between application instances?
Threats and Attacks
Category Items
Auditing and
Logging
Disclosure of confidential information. An attacker gathers sensitiveinformation from log files.
Denial of service (DoS). An attacker overwhelms logs with excessive entriesor very large log entries.
8/3/2019 0572.AzureSecurityNotes
11/121
Repudiation. An attacker denies performing an operation, exploits anapplication without trace, or covers his or her tracks.
Authentication Network eavesdropping. An attacker steals identity and/or credentials offthe network by reading network traffic not intended for them.
Brute force attacks. An attacker guesses identity and/or credentials throughthe use of brute force.
Dictionary attacks. An attacker guesses identity and/or credentials throughthe use of common terms in a dictionary designed for that purpose.
Cookie replay attacks. An attacker gains access to an authenticated sessionthrough the reuse of a stolen cookie containing session information.
Credential theft. An attacker gains access to credentials through data theft;for instance, phishing or social engineering.
Authorization Elevation of privilege. An attacker enters a system as a lower-level user, butis able to obtain higher-level access.
Disclosure of confidential data. An attacker accesses confidentialinformation because of authorization failure on a resource or operation.
Data tampering. An attacker modifies sensitive data because ofauthorization failure on a resource or operation.
Luring attacks. An attacker lures a higher-privileged user into taking anaction on their behalf. This is not an authorization failure but rather a failure
of the system to properly inform the user.
Token stealing. An attacker steals the credentials or token of another user inorder to gain authorization to resources or operations they would not
otherwise be able to access.
Communication Failure to encrypt messages. An attacker is able to read message content offthe network because it is not encrypted.
Theft of encryption keys. An attacker is able to decrypt sensitive databecause he or she has the keys.
Man-in-the-middle attack. An attacker can read and then modify messagesbetween the client and the service.
Session replay. An attacker steals messages off the network and replaysthem in order to steal a user's session.
Data tampering. An attacker modifies the data in a message in order toattack the client or the service
Configuration
Management
Unauthorized access to configuration stores. An attacker gains access toconfiguration files and is able to modify binding settings, etc.
Retrieval of clear text configuration secrets. An attacker gains access toconfiguration files and is able to retrieve sensitive information such as
database connection strings.
Cryptography Encryption cracking. Breaking an encryption algorithm and gaining access tothe encrypted data.
Loss of decryption keys. Obtaining decryption keys and using them to accessprotected data.
Exception
Management
Information disclosure. Sensitive system or application details are revealedthrough exception information.
Denial of service. An attacker uses error conditions to stop your service orplace it in an unrecoverable error state.
8/3/2019 0572.AzureSecurityNotes
12/121
Elevation of privilege. Your service encounters an error and fails to aninsecure state; for instance, failing to revert impersonation.
Input and Data
Validation
Canonicalization attacks. Canonicalization attacks can occur anytimevalidation is performed on a different form of the input than that which is
used for later processing. For instance, a validation check may be performed
on an encoded string, which is later decoded and used as a file path or URL. Cross-site scripting. Cross-site scripting can occur if you fail to encode user
input before echoing back to a client that will render it as HTML.
SQL injection. Failure to validate input can result in SQL injection if the inputis used to construct a SQL statement, or if it will modify the construction of a
SQL statement in some way.
Cross-Site Request Forgery: CSRF attacks involve forged transactionssubmitted to a site on behalf of another party.
XPath injection. XPath injection can result if the input sent to the Webservice is used to influence or construct an XPath statement. The input can
also introduce unintended results if the XPath statement is used by the Web
service as part of some larger operation, such as applying an XQuery or an
XSLT transformation to an XML document.
XML bomb. XML bomb attacks occur when specific, small XML messages areparsed by a service resulting in data that feeds on itself and grows
exponentially. An attacker sends an XML bomb with the intent of
overwhelming a Web services XML parser and resulting in a denial of service
attack.
Sensitive Data Memory dumping. An attacker is able to read sensitive data out of memoryor from local files.
Network eavesdropping. An attacker sniffs unencrypted sensitive data offthe network.
Configuration file sniffing. An attacker steals sensitive information, such asconnection strings, out of configuration files.
Vulnerabilities
Category Items
Auditing and
Logging
Failing to audit failed logons. Failing to secure log files. Storing sensitive information in log files. Failing to audit across application tiers. Failure to throttle log files.
Authentication Using weak passwords. Storing clear text credentials in configuration files. Passing clear text credentials over the network. Permitting prolonged session lifetime. Mixing personalization with authentication. Using weak authentication mechanisms (e.g., using basic authentication over
8/3/2019 0572.AzureSecurityNotes
13/121
an untrusted network).
Authorization Relying on a single gatekeeper (e.g., relying on client-side validation only). Failing to lock down system resources against application identities. Failing to limit database access to specified stored procedures. Using inadequate separation of privileges. Connection pooling. Permitting overprivileged accounts.
Configuration
Management
Using insecure custom administration interfaces. Failing to secure configuration files on the server. Storing sensitive information in the clear text. Having too many administrators. Using overprivileged process accounts and service accounts.
Communication Not encrypting messages. Using custom cryptography. Distributing keys insecurely. Managing or storing keys insecurely. Failure to use a mechanism to detect message replays. Not using either message or transport security.
Cryptography Using custom cryptography Failing to secure encryption keys Using the wrong algorithm or a key size that is too small Using the same key for a prolonged period of time Distributing keys in an insecure manner
Exception
Management
Failure to use structured exception handling (try/catch). Revealing too much information to the client. Failure to specify fault contracts with the client. Failure to use a global exception handler.
Input and DataValidation
Using non-validated input used to generate SQL queries. Relying only on client-side validation. Using input file names, URLs, or usernames for security decisions. Using application-only filters for malicious input. Looking for known bad patterns of input. Trusting data read from databases, file shares, and other network resources. Failing to validate input from all sources including cookies, headers,
parameters, databases, and network resources.
Sensitive Data Storing secrets when you do not need to. Storing secrets in code. Storing secrets in clear text in files, registry, or configuration. Passing sensitive data in clear text over networks.
Countermeasures
Category Items
8/3/2019 0572.AzureSecurityNotes
14/121
Auditing and
Logging
Identify malicious behavior. Know your baseline (know what good traffic looks like). Use application instrumentation to expose behavior that can be monitored. Throttle logging. Strip sensitive data before logging.
Authentication Use strong password policies. Do not store credentials in an insecure manner. Use authentication mechanisms that do not require clear text credentials to
be passed over the network.
Encrypt communication channels to secure authentication tokens. Use Secure HTTP (HTTPS) only with forms authentication cookies. Separate anonymous from authenticated pages. Using cryptographic random number generators to generate session IDs.
Authorization Use least-privileged accounts. Tie authentication to authorization on the same tier. Consider granularity of access. Enforce separation of privileges. Use multiple gatekeepers. Secure system resources against system identities.
Configuration
Management
Using insecure custom administration interfaces. Failing to secure configuration files on the server. Storing sensitive information in the clear text. Having too many administrators. Using overprivileged process accounts and service accounts.
Communication Use message security or transport security to encrypt your messages. Use proven platform-provided cryptography. Periodically change your keys. Use any platform-provided replay detection features. Consider creating custom code if the platform does not provide a detection
mechanism.
Turn on message or transport security.Cryptography Do not develop and use proprietary algorithms (XOR is not encryption. Use
established cryptography such as RSA)
Avoid key management. Use the RNGCryptoServiceProvider method to generate random numbers Periodically change your keys
Exception
Management
Use structured exception handling (by using try/catch blocks). Catch and wrap exceptions only if the operation adds value/information. Do not reveal sensitive system or application information. Implement a global exception handler. Do not log private data such as passwords.
Sensitive Data Do not store secrets in software. Encrypt sensitive data over the network. Secure the channel. Encrypt sensitive data in configuration files.
Validation Do not trust client input.
8/3/2019 0572.AzureSecurityNotes
15/121
Validate input: length, range, format, and type. Validate XML streams. Constrain, reject, and sanitize input. Encode output. Restrict the size, length, and depth of parsed XML messages.
Threats and Attacks Explained
1. Brute force attacks. Attacks that use the raw computer processing power to try differentpermutations of any variable that could expose a security hole. For example, if an attacker
knew that access required an 8-character username and a 10-character password, the
attacker could iterate through every possible (256 multiplied by itself 18 times) combination
in order to attempt to gain access to a system. No intelligence is used to filter or shape for
likely combinations.2. Buffer overflows. The maximum size of a given variable (string or otherwise) is exceeded,
forcing unintended program processing. In this case, the attacker uses this behavior to
cause insertion and execution of code in such a way that the attacker gains control of the
program in which the buffer overflow occurs. Depending on the programs privileges, the
seriousness of the security breach will vary.
3. Canonicalization attacks. There are multiple ways to access the same object and anattacker uses a method to bypass any security measures instituted on the primary intended
methods of access. Often, the unintended methods of access can be less secure deprecated
methods kept for backward compatibility.
4. Cookie manipulation. Through various methods, an attacker will alter the cookies stored inthe browser. Attackers will then use the cookie to fraudulently authenticate themselves to a
service or Web site.
5. Cookie replay attacks. Reusing a previously valid cookie to deceive the server into believingthat a previously authenticated session is still in progress and valid.
6. Credential theft. Stealing the verification part of an authentication pair (identity +credentials = authentication). Passwords are a common credential.
7. Cross-Site Request Forgery (CSRF). Interacting with a web site on behalf of another user toperform malicious actions. A site that assumes all requests it receives are intentional is
vulnerable to a forged request.
8. Cross-site scripting (XSS). An attacker is able to inject executable code (script) into a streamof data that will be rendered in a browser. The code will be executed in the context of theusers current session and will gain privileges to the site and information that it would not
otherwise have.
9. Connection pooling. The practice of creating and then reusing a connection resource as aperformance optimization. In a security context, this can result in either the client or server
using a connection previously used by a highly privileged user being used for a lower-
privileged user or purpose. This can potentially expose vulnerability if the connection is not
reauthorized when used by a new identity.
8/3/2019 0572.AzureSecurityNotes
16/121
10.Data tampering. An attacker violates the integrity of data by modifying it in local memory,in a data-store, or on the network. Modification of this data could provide the attacker with
access to a service through a number of the different methods listed in this document.
11.Denial of service. Denial of service (DoS) is the process of making a system or applicationunavailable. For example, a DoS attack might be accomplished by bombarding a server with
requests to consume all available system resources, or by passing the server malformedinput data that can crash an application process.
12.Dictionary attack. Use of a list of likely access methods (usernames, passwords, codingmethods) to try and gain access to a system. This approach is more focused and intelligent
than the brute force attack method, so as to increase the likelihood of success in a shorter
amount of time.
13.Disclosure of sensitive/confidential data. Sensitive data is exposed in some unintendedway to users who do not have the proper privileges to see it. This can often be done
through parameterized error messages, where an attacker will force an error and the
program will pass sensitive information up through the layers of the program without
filtering it. This can be personally identifiable information (i.e., personal data) or system
data.
14.Elevation of privilege. A user with limited privileges assumes the identity of a privilegeduser to gain privileged access to an application. For example, an attacker with limited
privileges might elevate his or her privilege level to compromise and take control of a highly
privileged and trusted process or account. More information about this attack in the
context of Windows Azure can be found in the Security Best Practices for Developing
Windows Azure Applications at
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-
dc54-4f56-aae7-481e67504df6
15.Encryption. The process of taking sensitive data and changing it in such a way that it isunrecognizable to anyone but those who know how to decode it. Different encryptionmethods have different strengths based on how easy it is for an attacker to obtain the
original information through whatever methods are available.
16.Information disclosure. Unwanted exposure of private data. For example, a user views thecontents of a table or file that he or she is not authorized to open, or monitors data passed
in plaintext over a network. Some examples of information disclosure vulnerabilities include
the use of hidden form fields, comments embedded in Web pages that contain database
connection strings and connection details, and weak exception handling that can lead to
internal system-level details being revealed to the client. Any of this information can be very
useful to the attacker.
17.Luring attacks. An attacker lures a higher-privileged user into taking an action on his or herbehalf. This is not an authorization failure but rather a failure of the system to properly
inform the user.
18.Man-in-the-middle attacks. A person intercepts both the client and server communicationsand then acts as an intermediary between the two without each ever knowing. This gives
the middle man the ability to read and potentially modify messages from either party in
order to implement another type of attack listed here.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df68/3/2019 0572.AzureSecurityNotes
17/121
19.Network eavesdropping. Listening to network packets and reassembling the messagesbeing sent back and forth between one or more parties on the network. While not an attack
itself, network eavesdropping can easily intercept information for use in specific attacks
listed in this document.
20.Open Redirects. Attacker provides a URL to a malicious site when allowed to input a URLused in a redirect. This allows the attacker to direct users to sites that perform phishingattacks or other malicious actions.
21.Password cracking. If the attacker cannot establish an anonymous connection with theserver, he or she will try to establish an authenticated connection. For this, the attacker
must know a valid username and password combination. If you use default account names,
you are giving the attacker a head start. Then the attacker only has to crack the accounts
password. The use of blank or weak passwords makes the attackers job even easier.
22.Repudiation. The ability of users (legitimate or otherwise) to deny that they performedspecific actions or transactions. Without adequate auditing, repudiation attacks are difficult
to prove.
23.Session hijacking. Also known as man-in-the-middle attacks, session hijacking deceives aserver or a client into accepting the upstream host as the actual legitimate host. Instead,
the upstream host is an attackers host that is manipulating the network so the attackers
host appears to be the desired destination.
24.Session replay. An attacker steals messages off of the network and replays them in order tosteal a users session.
25.Session fixation. An attacker sets (fixates) another persons session identifier artificially. Theattacker must know that a particular Web service accepts any session ID that is set
externally; for example, the attacker sets up a URL such as
http://unsecurewebservice.com/?sessionID=1234567. The attacker then sends this URL to a
valid user, who clicks on it. At this point, a valid session with the ID 1234567 is created on
the server. Because the attacker determines this ID, he or she can now hijack the session,which has been authenticated using the valid users credentials.
26.Spoofing. An attempt to gain access to a system by using a false identity. This can beaccomplished by using stolen user credentials or a false IP address. After the attacker
successfully gains access as a legitimate user or host, elevation of privileges or abuse using
authorization can begin.
27.SQL injection. Failure to validate input in cases where the input is used to construct a SQLstatement or will modify the construction of a SQL statement in some way. If the attacker
can influence the creation of a SQL statement, he or she can gain access to the database
with privileges otherwise unavailable and use this in order to steal or modify information or
destroy data.28.Throttling. The process of limiting resource usage to keep a particular process from bogging
down and/or crashing a system. Relevant as a countermeasure in DoS attacks, where an
attacker attempts to crash the system by overloading it with input.
8/3/2019 0572.AzureSecurityNotes
18/121
Countermeasures Explained
1. Assume all input is malicious. Assuming all input is malicious means designing yourapplication to validate all input. User input should never be accepted without being filtered
and/or sanitized.
2. Audit and log activity through all of the application tiers. Log business critical and securitysensitive events. This will help you track security issues down and make sense of security
problems. Skilled attackers attempt to cover their tracks, so youll want to protect your
logs.
3. Avoid storing secrets. Design around storing secrets. If necessary, sometimes they can beavoided by storing them after using a one-way hash algorithm.
4. Avoid storing sensitive data in the Web space. Anything exposed to the public Internet isconsidered web space. Sensitive data stored in a location that might be compromised by
any member of the public places it at much higher risk.
5. Back up and regularly analyze log files. Some attacks can occur over time. Regular analysisof logs will allow you to recognize with sufficient time to address them. Performing regularbackups lowers the risk of an attacker covering his tracks by deleting logging of his activities.
6. Be able to disable accounts. The ability to reactively defend an attack by shutting out a usershould be supported through the ability to disable an account.
7. Be careful with canonicalization issues. Predictable naming of file resources is convenientfor programming, but is also very convenient for malicious parties to attack. Application
logic should not be exposed to users in this manner. Instead, you use file names derived
from the original names or fed through a one-way hashing algorithm.
8. Catch exceptions. Unhandled exceptions are at risk of passing too much information to theclient. Handle exceptions when possible.
9.
Centralize your input and data validation. Input and data validation should be performedusing a common set of code such as a validation library.
10.Consider a centralized exception management framework. Exception handling frameworksare available publically and provide an established and tested means for handling
exceptions.
11.Consider authorization granularity. Every object needs to have an authorization controlthat authorizes access based on the identity of the authenticated party requesting access.
Fine grained authorization will control access to each resource, while coarse grained
authorization will control access to groups of resources or functional areas of the
application.
12.Consider identity flow. Auditing should be traceable back to the authenticated party. Takenote of identity transitions imposed by design decisions like impersonation.
13.Constrain input. Limit user input to expected ranges and formats.14.Constrain, reject, and sanitize your input. Constrain, reject and sanitize should be primary
techniques in handling input data.
15.Cycle your keys periodically. Expiring encryption keys lowers the risk of stolen keys.
8/3/2019 0572.AzureSecurityNotes
19/121
16.Disable anonymous access and authenticate every principle. When possible, require allinteractions to occur as an authenticated party as opposed to an anonymous one. This will
help facilitate more effective auditing.
17.Do not develop your own cryptography. Custom cryptography is not difficult for experts tocrack. Established cryptography is preferred because it is known to be safe.
18.Do not leak information to the client. Exception data can potentially contain sensitive dataor information exposing program logic. Provide clients only with the error data they need
for the UI.
19.Do not log private data such as passwords. Log files are an attack vector for maliciousparties. Limit the risk of their being compromised by not logging sensitive data in the log.
20.Do not pass sensitive data using the HTTP-GET protocol. Data passed using HTTP GET isappended to the querystring. When users share links by copying and pasting them from the
browser address bar, sensitive data may also be inadvertently passed. Pass sensitive data in
the body of a POST to avoid this.
21.Do not rely on client-side validation. Any code delivered to a client is at risk of beingcompromised. Because of this, it should always be assumed that input validation on the
client might have been bypassed.
22.Do not send passwords over the wire in plaintext. Authentication informationcommunicated over the wire should always be encrypted. This may mean encrypting the
values, or encrypting the entire channel with SSL.
23.Do not store credentials in plaintext. Credentials are sometimes stored in applicationconfiguration files, repositories, or sent over email. Always encrypt credentials before
storing them.
24.Do not store database connections, passwords, or keys in plaintext. Configuration secretsshould always be stored in encrypted form, external to the code.
25.Do not store passwords in user stores. In the event that the user store is compromised, anattack should never be able to access passwords. A derivative of a password should bestored instead. A common approach to this is to encrypt a version of the password using a
one-way hash with a SALT. Upon authentication, the encrypted password can be re-
generated with the SALT and the result can be compared to the original encrypted
password.
26.Do not store secrets in code. Secrets such as configuration settings are convenient to storein code, but are more likely to be stolen. Instead, store them in a secure location such as a
secret store.
27.Do not store sensitive data in persistent cookies. Persistent cookies are stored client-sideand provide attackers with ample opportunity to steal sensitive data, be it through
encryption cracking or any other means.28.Do not trust fields that the client can manipulate (query strings, form fields, cookies, or
HTTP headers). All information sent from a client should always be assumed to be
malicious. All information from a client should always be validated and sanitized before it is
used.
29.Do not trust HTTP header information. Http header manipulation is a threat that can bemitigated by building application logic that assumes HTTP headers are compromised and
validates the HTTP headers before using them.
8/3/2019 0572.AzureSecurityNotes
20/121
30.Encrypt communication channels to protect authentication tokens. Authentication tokensare often the target of eavesdropping, theft or replay type attacks. To reduce the risk in
these types of attacks, it is useful to encrypt the channel the tokens are communicated
over. Typically this means protecting a login page with SSL encryption.
31.Encrypt sensitive cookie state. Sensitive data contained within cookies should always beencrypted.
32.Encrypt the contents of the authentication cookies. In the case where cookies arecompromised, they should not contain clear-text session data. Encrypt sensitive data within
the session cookie.
33.Encrypt the data or secure the communication channel. Sensitive data should only bepassed in encrypted form. This can be accomplished by encrypting the individual items that
are sent over the wire, or encrypting the entire channel as with SSL.
34.Enforce separation of privileges. Avoid building generic roles with privileges to perform awide range of actions. Roles should be designed for specific tasks and provided the
minimum privileges required for those tasks.
35.Enforce unique transactions. Identify each transaction from a client uniquely to helpprevent replay and forgery attacks.
36.Identify malicious behavior. Monitoring site interactions that fall outside of normal usagepatterns, you can quickly identify malicious behavior. This is closely related to Know what
good traffic looks like.
37.Keep unencrypted data close to the algorithm. Use decrypted data as soon as it isdecrypted, and then dispose of it promptly. Unencrypted data should not be held in
memory in code.
38.Know what good traffic looks like. Active auditing and logging of a site will allow you knowrecognize what regular traffic and usage patterns are. This is a required step in order to be
able to identify malicious behavior.
39.Limit session lifetime. Longer session lifetimes provide greater opportunity for Cross-SiteScripting or Cross-Site Request Forgery attacks to add activity onto an old session.
40.Log detailed error messages. Highly detailed error message logging can provide clues toattempted attacks.
41.Log key events. Profile your application and note key or sensitive operations and/or events,and log these events during application operation.
42.Maintain separate administration privileges. Consider granularity of authorization in theadministrative interfaces as well. Avoid combining administrator roles with distinctly
different roles such as development, test or deployment.
43.Make sure that users do not bypass your checks. Bypassing checks can be accomplished bycanonicalization attacks, or bypassing client-side validation. Application design should avoidexposing application logic, and segregating application logic into flow that can be
interrupted. For example, an ASPX page that performs only validations and then redirects.
Instead, validation routines should be tightly bound to the data they are validating.
44.Pass Forms authentication cookies only over HTTPS connections. Cookies are at risk oftheft and replay type attacks. Encrypting them with SSL helps reduce the risk of these types
of attacks.
8/3/2019 0572.AzureSecurityNotes
21/121
45.Protect authentication cookies. Cookies can be manipulated with Cross-Site Scriptingattacks, encrypt sensitive data in cookies, and use browser features such as the HttpOnly
cookie attribute.
46.Provide strong access controls on sensitive data stores. Access to secret stores should butauthorized. Protect the secret store as you would other secure resources by requiring
authentication and authorization as appropriate.47.Reject known bad input. Rejecting known bad input involves screening input for values that
are known to be problematic or malicious. NOTE: Rejecting should never be the primary
means of screening bad input, it should always be used in conjunction with input
sanitization.
48.Require strong passwords. Enforce password complexity requirement by requiring longpasswords with a combination of upper case, lower case, numeric and special (for example
punctuation) characters. This helps mitigate the threat posed by dictionary attacks. If
possible, also enforce automatic password expiry.
49.Restrict user access to system-level resources. Users should not be touching systemresources directly. This should be accomplished through an intermediary such as the
application. System resources should be restricted to application access.
50.Retrieve sensitive data on demand. Sensitive data stored in application memory providesattackers another location they can attempt to access the data. Often this data is used in
unencrypted form also. To minimize risk of sensitive data theft, sensitive data should be
used immediately and then cleared from memory.
51.Sanitize input. Sanitizing input is the opposite of rejecting bad input. Sanitizing input is theprocess of filtering input data to only accept values that are known to be safe. Alternatively,
input can be rendered innocuous by converting it to safe output through output encoding
methods.
52.Secure access to log files. Log files should only be accessible to administrators, auditors, oradministrative interfaces. An attacker with access to the logs might be able to gleansensitive data or program logic from logs.
53.Secure the communication channel for remote administration. Eavesdropping and replayattacks can target administration interfaces as well. If using a web based administration
interface, use SSL.
54.Secure your configuration store. The configuration store should require authenticatedaccess and should store sensitive settings or information in an encrypted format.
55.Secure your encryption keys. Encryption keys should be treated as secrets or sensitive data.They should be secured in a secret store or key repository.
56.Separate public and restricted areas. Applications that contain public front-ends as well ascontent that requires authentication to access should be partitioned in the same manner.Public facing pages should be hosted in a separate file structure, directory or domain from
private content.
57.Store keys in a restricted location. Protect keys with authorization policies.58.Support password expiration periods. User passwords and account credentials are
commonly compromised. Expiration policies help mitigate attacks from stolen accounts, or
disgruntled employees who have been terminated.
8/3/2019 0572.AzureSecurityNotes
22/121
59.Use account lockout policies for end-user accounts. Account login attempts should have acap on failed attempts. After the cap is exceeded the account should prevent further login
attempts. Lockout helps prevent dictionary and brute force attacks.
60.Use application instrumentation to expose behavior that can be monitored: Applicationtransactions that are more likely to be targeted by malicious interactions should be logged
or monitored. Examples of this might be adding logging code to an exception handler, orlogging individual API calls. By providing a means to watch these transactions you have a
higher likelihood of being able to identify malicious behavior quickly.
61.Use authentication mechanisms that do not require clear text credentials to be passedover the network: A variety of authentication approaches exist for use with web based
applications some involve the use of tokens while others will pass user credentials (user
name/id and password) over the wire. When possible, it is safer to use an authentication
mechanism that does not pass the credentials. If credentials must be passed, it is preferable
to encrypt them, and/or send them over an encrypted channel such as SSL.
62.Use least privileged accounts. The privileges granted to the authenticated party should bethe minimum required to perform all required tasks. Be careful of using existing roles that
have permissions beyond what is required.
63.Use least privileged process and service accounts. Allocate accounts specifically for processand service accounts. Lock down the privileges of these accounts separately from other
accounts.
64.Use multiple gatekeepers. Passing the authentication system should not provide a goldenticket to any/all functionality. System and/or application resources should have restricted
levels of access depending on the authenticated party. Some design patterns might also
enforce multiple authentications, sometimes distributed through application tiers.
65.Use SSL to protect session authentication cookies. Session authentication cookies containdata that can be used in a number of different attacks such as replay, Cross-Site Scripting or
Cross-Site Request Forgery. Protecting these cookies helps mitigate these risks.66.Use strong authentication and authorization on administration interfaces. Always require
authenticated access to administrative interfaces. When applicable, also enforce separation
of privileges within the administrative interfaces.
67.Use structured exception handling. A structured approach to exception handling lowers therisk of unexpected exceptions from going unhandled.
68.Use the correct algorithm and correct key length. Different encryption algorithms arepreferred for varying data types and scenarios.
69.Use tried and tested platform features. Many cryptographic features are available throughthe .NET Framework. These are proven features and should be used in favor of custom
methods.70.Validate all values sent from the client. Similar to not relying on client-side validation, any
input from a client should always be assumed to have been tampered with. This input
should always be validated before it is used. This encompasses user input, cookie values,
HTTP headers, and anything else that is sent over the wires from the client.
71.Validate data for type, length, format, and range. Data validation should encompass theseprimary tenets. Validate for data type, string lengths, string or numeric formats, and
numeric ranges.
8/3/2019 0572.AzureSecurityNotes
23/121
SDL Considerations
For more information on preferred encryption algorithms and key lengths, see the SecurityDevelopment Lifecycle athttp://www.microsoft.com/security/sdl/.
http://www.microsoft.com/security/sdl/http://www.microsoft.com/security/sdl/http://www.microsoft.com/security/sdl/http://www.microsoft.com/security/sdl/8/3/2019 0572.AzureSecurityNotes
24/121
Design Guidelines for Improving Cloud Application Security
OverviewWhile many of the same security patterns and practices you apply to applications you run on-
premise, also apply to the cloud, you do need to think about how the context changes some
things. For example, running in the cloud means running your applications and data in an
environment where you trade control for economic or technical benefits.
Applications running in the cloud by their nature are Internet facing. Deployment patterns
change including where you run your code, and how it makes calls to other services or
applications. Running in the cloud means thinking in terms of virtualized resources. It also
means restricted access to some underlying system resources. Additionally, it means thinking
about the interfaces you expose, how you protect them, and the communication protocols you
use.
Running in the cloud also means rethinking security context, as well as identity management
and access controls, and considering approaches that allow you to integrate, leverage, and
interoperate with your existing resources or other services or systems in the cloud, or even with
on-premise systems and services.
For a synopsis view of changes to development introduced with Windows Azure, see the
Whats New with Windows Azure Cheat Sheet in the Appendix.
Windows Azure and Windows Identity Framework Impact
The following are points that will help you think about how Windows Azure and how WindowsIdentity Framework may impact your security design:
Claims -- You can use claims for identity management and for access control. Claims alignwell with cloud applications because they allow you to factor out identity management logic
from your application and integrate with identity providers such as an on-premise Active
Directory via Active Directory Federation Services.
VM model and trust -- The Windows Azure security model is centered around strict controlover VMs imposed by two Windows Azure specific trust policies which are defined as full
and partial trust. These policies limit access to system resources to prohibit common attacks
like elevation of privilege. A working knowledge of what level of permissions are available is
required to know which pieces of an existing application can be migrated and which must
be adjusted to work under more restrictive permissions.
For more information on full trust in Azure, seehttp://msdn.microsoft.com/en-
us/library/dd573363.aspxFor more information on partial trust in Azure, see
http://msdn.microsoft.com/en-us/library/dd573355.aspx
http://msdn.microsoft.com/en-us/library/dd573363.aspxhttp://msdn.microsoft.com/en-us/library/dd573363.aspxhttp://msdn.microsoft.com/en-us/library/dd573363.aspxhttp://msdn.microsoft.com/en-us/library/dd573363.aspxhttp://msdn.microsoft.com/en-us/library/dd573355.aspxhttp://msdn.microsoft.com/en-us/library/dd573355.aspxhttp://msdn.microsoft.com/en-us/library/dd573355.aspxhttp://msdn.microsoft.com/en-us/library/dd573363.aspxhttp://msdn.microsoft.com/en-us/library/dd573363.aspx8/3/2019 0572.AzureSecurityNotes
25/121
Azure Storage and SQL Azure -- Some of the things to think about in Windows Azureregarding data include deciding where to host your data, what will be used to host the data,
and what the means of access to that data will be. You can use on-premise data and expose
it as a service to your Windows Azure application. Data hosting in the cloud can be done
primarily through Windows Azure Storage or SQL Azure. Data exposed to other applications
or services should be exposed as a service (Data as a Service), but data consumed only byyour application has the option of being accessed without a service interface.
Deployment -- Deploying the Windows Azure can potentially mean deploying acrossmultiple data centers that are physically separate. This will influence application design
patterns, deployment, as well as communication between application pieces. Be aware of
your application boundaries, and use resources within the same data center when possible,
and communication options such as internal endpoints when applicable.
Architecture and Design Issues for Cloud Applications
When you design for the cloud, keep the following guidelines in mind:
Factor authentication and authorization logic from application logic. Use claims based authentication to integrate with existing user stores. Know the Windows Azure trust policy restrictions. Consider your storage options: Windows Azure Storage, SQL Azure, Azure Drives. Know the communication changes.
Factor authentication and authorization logic from application logic
Implementing authentication and authorization logic based on claims allows you to decoupleyour application logic from your identity logic. This provides for more secure applications by
standardizing around a common implementation of authentication logic around the WS-*
protocols. Having the identity logic separate makes the application more maintainable too, by
allowing updates or changes to authentication logic that does not impact the application.
Building around the WS-* protocols also provides for better interoperability.
Use claims based authentication to integrate with existing user stores
Established approaches to authentication and authorization are still valid in the cloud, but
claims and Single Sign-On (SSO) approaches provide strong integration with Active Directorybased authentication and federated identity. It is still possible to implement authentication
using ASP.NET forms authentication but this will involve creating a new user store. To leverage
an existing user store, or integrate with foreign user stores or an on-premise Active Directory,
you will want to use the Windows Identity Federation to use the WS-* protocols for a claims
based authentication solution.
8/3/2019 0572.AzureSecurityNotes
26/121
Know the Windows Azure trust policy restrictions
Code operating in a Windows Azure VM will operate with a more restrictive set of permissions.
The default is full trust which still contains a more restrictive set of permissions than an on-
premise solution. Some of the most prominent restrictions include the limited access to the
registry, and some basic file access restrictions as well. Avoid API's that require system level
permissions, or access to Operating System resources. Use internet friendly protocols for
service calls, and internal endpoints or queues for IPC.
Consider your storage options: Windows Azure Storage, SQL Azure, Azure
Drives
Windows Azure Storage and SQL Azure are the 2 primary storage options for Windows Azure
applications. Azure drives offer another option for persisting information, by writing to the
VM's virtual drive, and persisting the drive state to Azure Drives. SQL Azure offers relational
data storage and a host for existing TSQL logic. Windows Azure storage offers a lower cost per
megabyte stored.
Know the communications changes
Working inside of the Windows Azure data centers influences application design, from the
communication standpoint, in a number of ways. VM's are exposed to the public internet as a
sub-domain off of the cloudapp.net domain. This means a singular IP address will represent a
web role, but the Windows Azure load balancer will resolve the traffic to a VM represented by a
virtual IP address. Applications should not be designed with VM instances that depend on
specific IP addresses.
Be aware of network communication inside and outside of the Windows Azure data centers.
You can gain better performance by taking advantage of the higher bandwidth communications
within a data center, as opposed to reaching outside of the data center for services. This
becomes important because the latency introduced at this level can be exploited by attackers in
Denial of Service attacks.
Know that internal endpoints for Windows Azure roles exist that allow roles to perform IPC
within the data center using TCP based protocols. Both web and worker roles can expose
endpoints for tightly bound IPC, whereas Windows Azure Storage queues can be used for
loosely bound IPC. The following diagram represents a typical application of queues to perform
IPC.
8/3/2019 0572.AzureSecurityNotes
27/121
Web RoleLo
adB
alancer
VMs VMs
Worker Role
HTTP /
HTTPs
Storage
Message
Message
Message
Queue
IIS Write Read
Figure 1. Windows Azure Storage queues for IPC Typical model
Potential Application Security Vulnerabilities Summary
Hot Spot Description
Auditing and Logging Attacks made without a trace, unauthorized access to logs or audits, covering
tracks by removing audit or log events.
Authentication Identity spoofing, password cracking, elevation of privileges, and unauthorized
access.
Authorization Access to confidential or restricted data, tampering, and execution of
unauthorized operations.
Communication Eavesdropping, sniffing, replay attacks.
Configuration
Management
Unauthorized access to administration interfaces, ability to update
configuration data, and unauthorized access to user accounts and account
profiles.
Cryptography Access to confidential data or account credentials, or both.
Input and Data
Validation
Attacks performed by embedding malicious strings in query strings, form fields,
cookies, and HTTP headers. These include command execution, cross-site
scripting (XSS), SQL injection, and buffer overflow attacks.
Exception
Management
Denial of service and disclosure of sensitive system level details.
Sensitive Data.
Sensitive Data Confidential information disclosure and data tampering.
Deployment Considerations
8/3/2019 0572.AzureSecurityNotes
28/121
Data Centers and Distribution
Windows Azure data centers exist in pairs for each continental area supported. The Windows
Azure Portal allows you to specify which data center to deploy your application to. This
becomes particularly important for applications that are not deployed as a single package. For
example, if you deploy a web service to one data center, and then deploy an application that
uses that service in a different data center, you will experience more latency than if both are
deployed to the same data center. Also note that network traffic within a single data center will
be at a much higher level of performance than traffic that must reach the public Internet.
Consider the geographic location for your users when deciding which data center(s) to deploy
to. Determine which data center has the best network response times for your users and
deploy your application to this data center. For example, if your users mostly live in Ohio, the
Northern US data center located in Chicago will most likely offer the best response times for
these users. Confirm that network performance is superior from this data center, and deploy to
it.
Deployment packages are typically built from Visual Studio projects. A Visual Studio project can
contain any number of roles. Roles deployed as part of a single deployment package will be
deployed as a group and distributed in the data center in fairly close proximity to provide
optimal performance. The following diagram represents what a deployment in a single data
center might encompass.
8/3/2019 0572.AzureSecurityNotes
29/121
Windows Azure
Web RoleWeb Role Web RoleWeb RoleWeb Role
Presentation Layer
ASP.NET UI
Web Role
Services Layer
Service
Interfaces
80 80
Worker RoleWorker RoleWorker Role
Business Layer
Data Layer
BrowserMobile Rich Client
Silverlight
Front-end
Silverlight
Front-end
Silverlight
Front-end
SQL Azureor
Azure Storage
SQL Azureor
Azure Storage
SQL Azureor
Azure Storage
Figure 2. Single data center deployment application architecture
Locations for SQL Azure and Windows Azure Storage can be specified when establishing theservices. It is beneficial to specify the same data center for your application as you use for your
data.
Keep these things in mind when securing your Windows Azure application, and remember that
it is significantly easier to eavesdrop on traffic on the public Internet than it would be to
compromise security within an Azure data center and sniff traffic inside the data center.
Internal versus External Traffic
Windows Azure meters data transfer for billing. Metering is performed on traffic entering and
leaving the data center, but not inside the data center. Systems comprising of parts that must
communicate between VMs, should be deployed to the same data center to optimize
expenditures.
Be aware of Windows Azure affinity groups. Affinity groups tell Windows Azure to deploy
applications in similar areas within the data center. Doing this will minimize the number of
network hops within a data center and improve network performance for your application.
8/3/2019 0572.AzureSecurityNotes
30/121
Separation of Responsibilities and Deployment Environments
Separation of responsibilities should be considered for any Windows Azure deployment. This
means you should have clear policies defined for the roles of administrator, release manager,
developer, tester and any other appropriate role.
The Windows Azure Portal is accessible via 2 methods. A user interface that requires a Live ID to
access, and deployment APIs that require a deployment certificate. Multiple deployment
certificates can be added to a Windows Azure account. These certificates can be added to
Visual Studio and allow multiple distinct parties to deploy from Visual Studio to Windows Azure.
Because the Windows Azure Portal access is controlled by Live ID and deployment certificates,
policies should be established and include proper management and distribution of both the Live
ID and the deployment certificates. Developers should not be in charge of deployment, nor
management of the Windows Azure service. Test environments should be deployed separately
from production and staging environments.
Note that separation of deployment rights between staging and production environments will
prohibit the use of the Virtual IP (VIP) swapping feature in the Windows Azure Portal. This
feature allows you to instantly make your staging environment live. The VIP swapping feature
requires that both the deployment and staging deployments be under the same Windows
Azure Account.
Auditing and LoggingAuditing and logging involves the handling of security related events. Processes for storing the
events, monitoring them, and auditing the logs are covered here. Windows Azure introducessome additional considerations in this area due to changes in the logging systems and methods
for persisting the logs to permanent storage. Windows Azure applications will also need to build
methods for monitoring application health and providing notifications.
The following practices improve your application's auditing and logging:
Protect your logs. Consider identity flow. Audit and log access across the application. Sanitize data before logging. Back up and analyze logs regularly.
Protect your logs.
Auditing and logging in Windows Azure must be performed to a location that can be secured
and persisted. Event logging can be performed to Windows Azure's Monitoring Data Service.
Logs should then be persisted into a secure storage location such as Windows Azure Storage.
When persisting logs to storage, be sure to implement strong authentication and authorization
8/3/2019 0572.AzureSecurityNotes
31/121
against that storage location. Also be aware that access to Windows Azure storage will be via
the RESTful interfaces and should therefore be secured over SSL.
For more information about auditing and logging, see the Security Best Practices for Developing
Windows Azure Applications at
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6.
Consider identity flow.
In Windows Azure, application architectures will commonly flow identities through a common
channel. Examples of this would be users authenticating against a web site, and data access to
Windows Azure Storage occurring over a common connection, or a common connection string
for SQL Azure. Be aware of this identity flow, and be sure to have a way of mapping data access
back to the authenticated user. This might be accomplished by passing a user identifier with the
data access and storing this with the transaction. Be sure to protect the identifier with a one-way hash if it is not passed over an encrypted channel.
Audit and log across the application.
Audits and logged events should occur at all levels of the application. When implementing
logging, be aware of the implications of excessive logging. Excessive logging can lead to
degradation of performance and might be exploited to cause a failure in the service in a Denial
of Service attack. In cases where extensive logging may be required for debugging purposes,
consider implementing logging levels that can be configured through an administrative
interface. This allows you to obtain detailed logs when required, but not degrade performance
when debugging isnt being performed.
Be sure to log at all locations in code where authentication or authorization takes place.
Additionally, be sensitive to transitions in identity such as using a common identity to connect
to a web service such as with a WCF binding using a server certificate for service authentication.
Review your application logic flow for key events, and be sure to log these events. Be sure to
log both success and failure events.
Include enough information in your logs to reconstruct the user interaction across all levels of
the site. With a site that is potentially logging events from several different requests at thesame time, it is important to be able to associate log events together. A common means of
accomplishing this is to assign a log identifier to be included with all logged events for a
particular transaction. Doing this allows you to filter the log based on an id to reconstruct the
event flow. Do not use a session id or other sensitive information for this identifier.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df68/3/2019 0572.AzureSecurityNotes
32/121
Sanitize data before logging.
Logged information should not contain any sensitive information or information that allows an
attacker to determine the logic of the application. Assume that an attacker can gain access to
the logs, and ensure that information that reaches the logs does not contain anything the
attacker can use. Logged information should be passed through a sanitization process before
being sent to the log. This process should strip out sensitive information such as credentials,
authentication tokens, file names, and application function names (such as in a call stack).
Back up and analyze log files.
Evaluate your strategy for maintaining historical log information. Windows Azure Storage can
provide up to 100TB of storage for logging data and is implicitly backed up in accordance with
the Windows Azure SLA. If you establish an archival process, be sure that the archives also have
a backup process in place.
Perform regular analysis on your log files to recognize normal usage patterns. This allows you to
quickly recognize irregular patterns which might be attacks.
AuthenticationAuthentication involves verifying the identity of parties accessing your application or services.
In Windows Azure, standard username and password credential based systems are possible, as
well as claims based identity frameworks that are well suited for cloud implementations.
The following practices improve your application's authentication:
Do not send passwords over the wire in plaintext. Do not store passwords in user stores. Separate public and restricted areas. Use established password policies.
Do not send passwords over the wire in plaintext.
Authenticating against a user id and password combination does not require these credentials
to be passed over the wire in order to authenticate. Use established practices to convert the
credentials into a secure form before transmitting them over the wire. By leveraging a claims
based authentication system based on WS* and Windows Identity Federation, you gain this
benefit. A claims based authentication system will authenticate by passing tokens over the wireinstead of credentials.
If you use an alternate authentication system, you should also avoid transferring credentials
over the wire. A typical approach is to perform a one-way hash on the password, and generate
the same hash on the server-side and comparing the results.
8/3/2019 0572.AzureSecurityNotes
33/121
Be aware of using email to distribute passwords or as part of your password reset procedures.
Instead of passing the user credentials in email, consider an alternate approach allowing users
to use alternate means to identify themselves (such as secrets) in the UI and reset the
password.
Do not store passwords in user stores.
This policy strongly relates to not sending passwords over the wire. Passwords should not be
stored in the user store or database. Instead, one-way hash the password using a SALT (a
cryptographically strong random number) and store the SALT and the hashed value in the user
store. These 2 items allow you to repeat the procedure when a user authenticates and compare
the hashed results.
Use established password management policies.
Password policies are established to lessen the vulnerability to dictionary or brute-force attacksagainst authentication. These policies include:
Require strong passwords. Strong password policies should encompass minimum passwordlength, and use of alpha-numeric and special characters.
Enforce requirements when using a passphrase. Passphrases should also have minimumrequirements for number of characters, and potentially special characters too.
Enforce password expiration periods. Use account lockout policies for end-user accounts. Support administrative disabling of accounts. Maintain a password history, but do not store the actual password as described above.
AuthorizationAuthorization covers the control over accessing resources within your application. In Windows
Azure these resources also include controlling access to Windows Azure Storage, SQL Azure and
WCF services. Traditional Role Based Authorization Control (RBAC) and claims based systems
are covered here.
The following practices improve your application's authorization:
Use multiple gatekeepers.
Consider authorization granularity. Restrict user access to system-level resources. Use RESTful interfaces carefully Separate public and restricted areas.
8/3/2019 0572.AzureSecurityNotes
34/121
Use multiple gatekeepers.
You should have one entry point that is secured. Within that channel, you might setup multiple
gatekeepers, so that in the event there is a compromise, you can slow an attacker down, by
creating more hurdles to jump through - or multiple choke-points for your application.
However, you have to balance the complexity of multiple gatekeepers with keeping your design
simple and easy to manage.
Consider authorization granularity.
When using a Role Based Authorization Control (RBAC) approach, ensure that the roles you
define are distinct enough to allow explicit access control without affecting other roles. For
example, if you wish to grant access of administration interfaces to administrators, other roles
such as database administrators should not also receive access. Careful analysis of your
application's users is necessary to determine the roles necessary and avoid enforce proper
separation of privileges between roles.
Restrict user access to system-level resources.
Windows Azure web roles and worker roles operate with the policy restrictions defined by
Windows Azure Partial Trust and full trust levels. Due to the restrictions defined by these
policies, access to system-level resources is prohibited and therefore implicitly supported by
the Windows Azure environment.
For more information on trust policy restrictions can be found at
http://msdn.microsoft.com/en-us/library/dd573355.aspx.
Use RESTful interfaces carefully
RESTful interfaces are designed to convey information about their logical function and the data
or information they return in the URL. The nature of this design makes it easy to inadvertently
expose application logic or structure to attackers. When implementing RESTful interfaces, be
sure to implement authorization against the interfaces with AppFabric Access Control whenever
possible. If authorization is not possible, it is recommended to only expose data for reading
with RESTful interfaces. Operations against the data should be accessed through an authorized
interface.
When designing RESTful interfaces, follow established practices that dictate exposing data can
be performed with HTTP GET requests, whereas modification of data via Create, Update or
Delete operations should be done using an HTTP POST.
http://msdn.microsoft.com/en-us/library/dd573355.aspxhttp://msdn.microsoft.com/en-us/library/dd573355.aspxhttp://msdn.microsoft.com/en-us/library/dd573355.aspx8/3/2019 0572.AzureSecurityNotes
35/121
Separate public and restricted areas.
For web applications it is important to separate public and restricted areas of the application.
Use this approach over securing files by name in the web.config tag. By
securing pages by directory, there are no additional steps necessary to secure the page after
placing it in the secure directory. This lowers the chance that an error could be made due to
failure to make settings in a configuration file like the web.config.
CommunicationCommunication encompasses how data is transmitted over the wire. This includes encrypting
the entire channel for applications with SSL, but also security web services with transport or
message based security. Certificate and key management for SSL are also topics covered here.
The following practices improve your application's communication security:
Windows Azure Storage should not use container names based on user input. Protect sensitive data over the wire. Periodically change your keys. Optimize communication security over performance. Check for accidental information disclosure.
Windows Azure Storage should not use container names based on user
input.
Windows Azure Storage is accessed using RESTful interfaces. This can place data at risk of
injection attacks if the attacker is able to affect the URI being called during data operations.
Because of this, it is recommended avoid using user input for Windows Azure Storage names
when possible. In the event that user input is needed, be sure to sanitize the user input byencoding it before using it.
For more information on this, see Security Best Practices for Developing Windows Azure
Applications at
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-
4f56-aae7-481e67504df6.
Protect sensitive data over the wire.
Sensitive information such as authentication information, personal information, or other HighBusiness Impact (HBI) data should never be transferred over the wire in clear-text. Web
applications should encrypt the channel with SSL, or encrypt data items before sending them
over the wire. WCF services should protect sensitive data with either message security or
transport security.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df68/3/2019 0572.AzureSecurityNotes
36/121
Periodically change your keys.
In Windows Azure, SSL encryption relies on X509 certificates uploaded to the Windows Azure
portal administration interface. These certificates are used to encrypt the SSL channel and may
also be used as keys for other encryption such as RSA. To help