windows azure security notes (pdf) - microsoft · azure security notes ... our goal is to show how...

Azure Security Notes Lessons Learned from

Exploring Microsoft Azure and the Cloud Security Space

J.D. Meier, Principal PM, Microsoft Paul Enfield

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

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

Overview These 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 and engineering 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 Nutshell We 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 problems are, and they’ll say it’s 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.aspx encapsulates the idea of trusting the application identity rather than every caller. Practices are simply actions, methods, or techniques. For example, you can use patterns & practices Threat Modeling http://msdn.microsoft.com/en-us/library/ff648006.aspx to shape the security design of your application.

• Threats and countermeasures. One way to make security actionable and prescriptive is to focus 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.aspx�


• 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 A’s: Authentication, Access control, and Auditing. We’ve 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”, “Configuration Management”, “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 at security. 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, what’s 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 Started Tackling 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 didn’t 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.



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 Focus One 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 security know-how.

Example Application Scenario and Solution Each 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

Solution

Solution Summary Table Area Notes Authentication • Authenticate users with forms authentication

• Store users in Azure Tables • Use TableStorageMembershipProvider for membership API’s • 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 API’s • 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 Frame A 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

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 Forward Improving 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

DatabaseServer

Fire

wal

l Apps

Fire

wal

l Apps

Host Host

Patches and UpdatesServicesProtocols

AccountsFiles and DirectoriesShares

Securing the Host

Host

RouterFirewallSwitch

Securing the Network Ports

RegistryAuditing and Logging

Threats and Countermeasures

Exception ManagementParameter ManipulationSensitive DataSession ManagementValidation

Auditing and LoggingAuthenticationAuthorizationConfiguration Mgt.Cryptography

Securing the Application


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.

Fire

wal

l Apps

Cloud Host

Threats and Countermeasures

Data

Application Layer

ManagedInfrastructure

DatabaseLayer

Patches and UpdatesServicesProtocols

AccountsFiles and DirectoriesShares

PortsRegistryAuditing and Logging

Securing the Host

CryptographyException ManagementSensitive DataSession ManagementValidation

Auditing and LoggingAuthenticationAuthorizationCommunicationConfiguration 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.

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.

Overview It is important to think like an attacker when designing and implementing an application. Putting yourself in the attacker’s mindset will make you more effective at designing mitigations for vulnerabilities and coding defensively. This section is a reference of the security frame, and its 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 Countermeasures This 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 a

system 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 Frame The 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

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. Transport security, 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 instances in 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 sensitive information from log files.

• Denial of service (DoS). An attacker overwhelms logs with excessive entries or very large log entries.

• Repudiation. An attacker denies performing an operation, exploits an application without trace, or covers his or her tracks.

Authentication • Network eavesdropping. An attacker steals identity and/or credentials off the network by reading network traffic not intended for them.

• Brute force attacks. An attacker guesses identity and/or credentials through the use of brute force.

• Dictionary attacks. An attacker guesses identity and/or credentials through the use of common terms in a dictionary designed for that purpose.

• Cookie replay attacks. An attacker gains access to an authenticated session through 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, but is able to obtain higher-level access.

• Disclosure of confidential data. An attacker accesses confidential information because of authorization failure on a resource or operation.

• Data tampering. An attacker modifies sensitive data because of authorization failure on a resource or operation.

• Luring attacks. An attacker lures a higher-privileged user into taking an action 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 in order 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 off the network because it is not encrypted.

• Theft of encryption keys. An attacker is able to decrypt sensitive data because he or she has the keys.

• Man-in-the-middle attack. An attacker can read and then modify messages between the client and the service.

• Session replay. An attacker steals messages off the network and replays them in order to steal a user's session.

• Data tampering. An attacker modifies the data in a message in order to attack the client or the service


• Unauthorized access to configuration stores. An attacker gains access to configuration files and is able to modify binding settings, etc.

• Retrieval of clear text configuration secrets. An attacker gains access to configuration files and is able to retrieve sensitive information such as database connection strings.

Cryptography • Encryption cracking. Breaking an encryption algorithm and gaining access to the encrypted data.

• Loss of decryption keys. Obtaining decryption keys and using them to access protected data.


• Information disclosure. Sensitive system or application details are revealed through exception information.

• Denial of service. An attacker uses error conditions to stop your service or place it in an unrecoverable error state.

• Elevation of privilege. Your service encounters an error and fails to an insecure state; for instance, failing to revert impersonation.


• Canonicalization attacks. Canonicalization attacks can occur anytime validation 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 input is 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 transactions submitted to a site on behalf of another party.

• XPath injection. XPath injection can result if the input sent to the Web service 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 are parsed 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 service’s XML parser and resulting in a denial of service attack.

Sensitive Data • Memory dumping. An attacker is able to read sensitive data out of memory or from local files.

• Network eavesdropping. An attacker sniffs unencrypted sensitive data off the network.

• Configuration file sniffing. An attacker steals sensitive information, such as connection 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

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.


• 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


• 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.


• 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

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.


• 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


• 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.

• 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 different

permutations 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 program’s privileges, the seriousness of the security breach will vary.

3. Canonicalization attacks. There are multiple ways to access the same object and an attacker 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 in the 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 believing that 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 to perform 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 stream of data that will be rendered in a browser. The code will be executed in the context of the user’s 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 a performance 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.

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 application unavailable. 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 malformed input data that can crash an application process.

12. Dictionary attack. Use of a list of likely access methods (usernames, passwords, coding methods) 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 unintended way 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 privileged user 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 is unrecognizable to anyone but those who know how to decode it. Different encryption methods 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 the contents 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 her behalf. 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 communications and 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-481e67504df6�


19. Network eavesdropping. Listening to network packets and reassembling the messages being 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 URL used in a redirect. This allows the attacker to direct users to sites that perform phishing attacks or other malicious actions.

21. Password cracking. If the attacker cannot establish an anonymous connection with the server, 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 account’s password. The use of blank or weak passwords makes the attacker’s job even easier.

22. Repudiation. The ability of users (legitimate or otherwise) to deny that they performed specific 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 a server or a client into accepting the upstream host as the actual legitimate host. Instead, the upstream host is an attacker’s host that is manipulating the network so the attacker’s host appears to be the desired destination.

24. Session replay. An attacker steals messages off of the network and replays them in order to steal a user’s session.

25. Session fixation. An attacker sets (fixates) another person’s session identifier artificially. The attacker 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 user’s credentials.

26. Spoofing. An attempt to gain access to a system by using a false identity. This can be accomplished 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 SQL statement 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.

Countermeasures Explained 1. Assume all input is malicious. Assuming all input is malicious means designing your

application 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 security sensitive events. This will help you track security issues down and make sense of security problems. Skilled attackers attempt to cover their tracks, so you’ll want to protect your logs.

3. Avoid storing secrets. Design around storing secrets. If necessary, sometimes they can be avoided 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 is considered “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 analysis of logs will allow you to recognize with sufficient time to address them. Performing regular backups 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 user should be supported through the ability to disable an account.

7. Be careful with canonicalization issues. Predictable naming of file resources is convenient for 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 the client. Handle exceptions when possible.

9. Centralize your input and data validation. Input and data validation should be performed using a common set of code such as a validation library.

10. Consider a centralized exception management framework. Exception handling frameworks are available publically and provide an established and tested means for handling exceptions.

11. Consider authorization granularity. Every object needs to have an authorization control that 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. Take note 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.

16. Disable anonymous access and authenticate every principle. When possible, require all interactions 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 to crack. 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 data or 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 malicious parties. 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 is appended 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 being compromised. 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 information communicated 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 application configuration files, repositories, or sent over email. Always encrypt credentials before storing them.

24. Do not store database connections, passwords, or keys in plaintext. Configuration secrets should 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, an attack should never be able to access passwords. A derivative of a password should be stored 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 store in 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-side and 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 be mitigated by building application logic that assumes HTTP headers are compromised and validates the HTTP headers before using them.

30. Encrypt communication channels to protect authentication tokens. Authentication tokens are 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 be encrypted.

32. Encrypt the contents of the authentication cookies. In the case where cookies are compromised, 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 be passed 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 a wide 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 help prevent replay and forgery attacks.

36. Identify malicious behavior. Monitoring site interactions that fall outside of normal usage patterns, 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 is decrypted, 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 know recognize 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-Site Scripting 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 to attempted 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 the administrative 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 by canonicalization attacks, or bypassing client-side validation. Application design should avoid exposing 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 of theft and replay type attacks. Encrypting them with SSL helps reduce the risk of these types of attacks.

45. Protect authentication cookies. Cookies can be manipulated with Cross-Site Scripting attacks, 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 but authorized. 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 long passwords 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 system resources 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 provides attackers 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 the process 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, or administrative interfaces. An attacker with access to the logs might be able to glean sensitive data or program logic from logs.

53. Secure the communication channel for remote administration. Eavesdropping and replay attacks 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 authenticated access 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 as content 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.

59. Use account lockout policies for end-user accounts. Account login attempts should have a cap 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: Application transactions 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, or logging 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 passed over 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 be the 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 process and 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 golden ticket 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 contain data 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 the risk of unexpected exceptions from going unhandled.

68. Use the correct algorithm and correct key length. Different encryption algorithms are preferred for varying data types and scenarios.

69. Use tried and tested platform features. Many cryptographic features are available through the .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 these primary tenets. Validate for data type, string lengths, string or numeric formats, and numeric ranges.

SDL Considerations • For more information on preferred encryption algorithms and key lengths, see the Security

Development Lifecycle at http://www.microsoft.com/security/sdl/.

http://www.microsoft.com/security/sdl/�

Design Guidelines for Improving Cloud Application Security

Overview While 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 What’s 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 Windows Identity Framework may impact your security design: • Claims -- You can use claims for identity management and for access control. Claims align

well 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 control over 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, see http://msdn.microsoft.com/en-us/library/dd573363.aspx For 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.aspx�



• Azure Storage and SQL Azure -- Some of the things to think about in Windows Azure regarding 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 by your application has the option of being accessed without a service interface.

• Deployment -- Deploying the Windows Azure can potentially mean deploying across multiple 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 decouple your 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 Directory based 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.

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.

Web Role

Load

Bal

ance

r

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.


Denial of service and disclosure of sensitive system level details. Sensitive Data.

Sensitive Data Confidential information disclosure and data tampering.

Deployment Considerations

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.

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



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 the services. 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.

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 API’s 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 Logging Auditing 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 introduces some 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

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 isn’t 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 the same 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.



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.

Authentication Authentication 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 wire instead 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.

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 attacks against authentication. These policies include: • Require strong passwords. Strong password policies should encompass minimum password

length, and use of alpha-numeric and special characters. • Enforce requirements when using a passphrase. Passphrases should also have minimum

requirements 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.

Authorization Authorization 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.

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.


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 <authorization> 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.

Communication Communication 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 by encoding 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 High Business 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.



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 reduce the risk of a compromised key or certificate, a policy should be in place to change and manage your X509 certificates. Note that cycling of keys should also be performed for any Windows Azure Storage accounts you use as well. Use the Portal features for regenerating access keys and establish a policy for distributing these as well.

Optimize communication security over performance. Security operations require extra work to process the data sent over the wire. Security related operations may include authentication, encryption/decryption, signing/verifying, hashing/verifying. Obviously to achieve a better performance you should trade off for loose security and vice versa. It's good to have in mind when designing communication strategy that different authentication schemes incur different level of performance. The bigger messages and payloads sent over the wire the longer it takes to process in terms of encryption, signing, hashing, and related operations. It also requires more resources such as memory and CPU.

Check for accidental information disclosure. To reduce revealing sensitive information, identify your sensitive data for your business and customers and be able to trace the paths. This will help you identify potential leaks. Check that the right authorization levels and access controls are in place. Make sure you don’t reveal sensitive information in application exceptions. Avoid showing exceptions that can reveal platform information or sensitive data for customers or the business. Make sure that your configuration protects against directory browsing

Configuration Management Configuration management involves the securing of both application configuration as well as administration interfaces. In Windows Azure this includes the Windows Azure Portal and issues surrounding configuration and configuration stores. The following practices improve your application's configuration management: • Maintain separate administration privileges. • Use separate storage accounts. • Don’t test with production data. • Encrypt sensitive data in configuration files. • Protect your administration interfaces.

Maintain separate administration privileges. Administration of Windows Azure applications will occur through the Windows Azure portal administration interface, and any additional custom administration interfaces you develop. Portal UI access is controlled by a Live ID, and access to the API's is controlled by client certificates. Define policies for the management of the administrator Live ID, and certificates. Enforce separation of privileges when defining these policies. Administrative portal UI access should not be given to developers, and deployment certificates should be only be provided to parties responsible for deployment. Additionally, be aware of privilege levels between environments. Enforce separation of privileges by implementing privilege levels appropriate for both role and environment. If live staging and or test environments are used, the same Live ID should not be used for staging or test, and for production. This also holds true for any custom administration interfaces you have implemented.

Use separate storage accounts. As mentioned above the Windows Azure Portal is responsible for securing the configuration settings at a Live ID account level. Access to application configuration stores should require authorization as well. For the highest level of security with Windows Azure Storage a separate storage account requiring a distinct storage key can be used to separate configuration settings from application data. Alternatively, authorization for access to the configuration store can be implemented at the code or API level. For more information on using a separate storage account, 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 .

Encrypt sensitive data in configuration files. Configuration settings may need to be encrypted as well. Configuration settings stored in configuration files (such as the web.config), that contain sensitive information (such as SQL connection strings) should be encrypted. For more information on encryption strategies in Windows Azure see Cryptography below.

Don’t test with production data. Use only test data in your test environments. Don’t use production data to test. Maintain separation of production data from test data. Production data should not be ported to the test environment, and test environments should never connect directly to live data.



Protect your custom administration interfaces. Custom administrative interfaces require access control as well. These interfaces should be restricted just as other application resources are. Access should be restricted to administrators, and usage should be audited.

Cryptography Cryptography in Windows Azure exposes some differences from on-premise solutions. Security restrictions imposed by the Windows Azure trust policies will require alternate approaches to handling of secure stores and encryption. The following practices improve your application's cryptographic processes: • Don’t roll your own cryptography. • Protect your encryption keys. • Don’t use encrypted values as index columns or partition keys. • Use the correct algorithm and correct key length. • Maintain different keys for different environments.

Don’t roll your own cryptography. Don’t roll your own cryptography. Use standard encryption algorithms such as AES or RSA. RSA should be used for asymmetric encryption and decryption. RSA encryption requires a key pair for encryption/decryption. To install a key pair, the key pair must be deployed with the application in a key file. Key files should not be left in the Azure VM after deployment, however Windows Azure permissions prevent the deletion of a key file after deployment. To work around this restriction, use the Windows Azure Portal to deploy an X509 certificate with a key pair. This key pair can be used for RSA encryption/decryption.

Secure your encryption keys. Encryption keys should be stored in a secure location, and should not be hard-coded into the application code. The Windows Azure Portal certificate store currently provides the best support for managing keys in the form of a secure certificate store. Policies for key rotation, generation, destruction, and revocation should be defined as operational policies.

Do not use encrypted values as index columns or partition keys. Encrypting data in a relational database is problematic if you want to index on it. You would have to encrypt the index as well as the data otherwise security is lost, but given the current indexing technology, encrypting keys would destroy the data distribution that allows for balance trees and relatively constant data access.

Use the correct algorithm and correct key length. Different encryption algorithms exist for varying encryption scenarios. In general, use AES for symmetric encryption, RSA for asymmetric encryption, and SHA for hashing. More detailed information on encryption key lengths can be found in Security Best Practices for Developing Windows Azure Applications.

Maintain different keys for different environments Enforce separation of encryption keys. Separate keys should be created for each environment; development, test, staging, production so a compromise in one environment will not jeopardize other environments.

Exception Management Exception management encompasses the handling of errors and exceptions in your application. Practices in this area are largely the same as for on-premise solutions. The following practices improve your application's exception handling: • Catch exceptions, and fail gracefully. • Log detailed error messages. • Do not leak information to the client. • Determine exception strategy at your boundaries.

Catch exceptions, and fail gracefully. Implement exception handling that will catch all exceptions, both expected and unexpected. Error messages returned to the client should be friendly errors. Application logic should continue to flow after errors, and not leave the application in an unusable state.

Log detailed error messages. Exception handling routines should not only trap errors, but they should also log the errors. Be sure to provide sufficient detail to determine the context of the error without including details about the internal application flow.

Do not leak information to the client. Error handling should provide feedback to the client, but the messages should be friendly and not contain internal application details. Common error scenarios should be mapped to error numbers which are safe to expose to the client. Stack dumps and debug error messages should be filtered from being delivered to the client.

Determine exception strategy at your boundaries. Determine your application boundaries and ensure that exceptions at these boundaries are handled. For example, if your application calls a web service, do not assume that the web service will gracefully handle invalid parameters. Instead, design your application to expect errors at boundaries and handle them gracefully.

Input and Data Validation Validation involves filtering of input and data from untrusted sources. Before input or data is processed by your application it should be verified to be safe by using established practices for filtering, scrubbing and sanitizing. Windows Azure Storage exposes another source for data that should be addressed when building validation routines for the cloud. The following practices further improve your input and data validation: • Validate data for length, range, format and type. • Constrain, reject, and sanitize your input. • Uniquely identify transactions. • Implement policies around BLOB handling. • Sanitize output.

Validate data for length, range, format and type. Validate data using established techniques that limit input by data type, and hold it to expected ranges. • Text values should fall have a maximum length, and longer values should be truncated or

rejected • Numeric values should fall within an expected range of values • Text values should meet expected formats • Data should be validated against the expected data type For more information on how to validate for length, range, format, and type, see the help file contained in the Web Client Guidance project at http://webclientguidance.codeplex.com/releases/view/46436 .

Constrain, reject and sanitize your input. Understanding what good input looks like will allow you to build constraints around what values will be accepted as input. The primary means of screening input data is by using a white-list approach where known-good values are accepted and others are rejected.

http://webclientguidance.codeplex.com/releases/view/46436�

For more information on how to implement this can be found in the How to: Perform Input and Data Validation chapter in http://webclientguidance.codeplex.com/releases/view/46436.

Uniquely identify transactions. Cross-Site Request Forgery attacks target sites that assume any submitted form is from a valid user. To ensure that transactions are not forged by an attacker, prevent them from being submitted multiple times by uniquely identifying them with a token that can easily be identified if tampered with. For more information on how to uniquely identify transactions, see “Cross-Site Request Forgery” in the help file contained in http://webclientguidance.codeplex.com/releases/view/46436.

Implement policies around BLOB handling. Windows Azure applications will commonly use Windows Azure Storage for handling of large objects and files. When supporting file uploads it is a good idea to implement throttling on file uploads to help prevent Denial of Service attacks. For additional considerations surrounding the handling of BLOBs, refer to the Security Best Practices for Developing Windows Azure Applications document.

Sanitize output. Input can host harmful script or other components. Encode any output that is derived from input, as this will render it harmless. Use an established encoding library like the Anti-Cross Site Scripting Library at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=051ee83c-5ccf-48ed-8463-02f56a6bfc09. Specifics on this and other encoding practices can be found in Input and Data Validation in the Web Client Guidance project at http://webclientguidance.codeplex.com/releases/view/46436.

Additional Considerations The following are some additional considerations: • Assume all input, and/or untrusted data is malicious. • Validate all values sent from client. • Make sure that users do not bypass your checks


http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=051ee83c-5ccf-48ed-8463-02f56a6bfc09�

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=051ee83c-5ccf-48ed-8463-02f56a6bfc09�


Sensitive Data Personal data and High Business Impact (HBI) data must be protected in your application. This includes sensitive data in persistent storage, as well as data in memory and passed over the network. In Windows Azure additional communication channels exist that should be handled when considering sensitive data. The following practices improve your application's handling of sensitive data: • Encrypt the data or secure the communication channel. • Do not store secrets if you can avoid it. • Do not store secrets in code. • Do not store database connections, passwords, or keys in plaintext. • Do not pass sensitive data using the HTTP-GET protocol.

Encrypt the data or secure the communication channel. Be aware of any sensitive data that is transmitted over the wire. In Windows Azure be aware that any persistent storage will transmit data over the wire, unlike on-premise applications which can save to the local drive. Windows Azure VM drives will be stored in Windows Azure Storage if persisted, which will occur over HTTP or HTTPS due to the RESTful interfaces of Windows Azure Storage. Data stored to SQL Azure will occur over a TDS pipe that can be encrypted as well. When saving to Windows Azure Storage, protect data by using HTTPS. When saving to SQL Azure, protect the connection by using the Encrypt=true property in the connection string. If you cannot secure the communication channel with SSL or encryption, encrypt the values sent over the wire instead. For distributed systems where data is encrypted at one end and then decrypted on another system, use RSA encryption. For data that is decrypted within the same application as it is encrypted, use AES encryption. Further information about encryption and key lengths can be found in the Microsoft Security Development Lifecycle at http://www.microsoft.com/security/sdl/.

Do not store secrets if you can avoid it. Storing sensitive data in persistent storage can sometimes be avoided. Consider alternate application logic that might allow you to avoid storing secrets. The most common example of this is storing hashed passwords and comparing the results of a hash against the stored value. This way the original value is never stored, yet the ability to screen based on the password still exists.

Do not store secrets in code. Code files are not a secure store. Code can be decompiled or reverse engineered to extract secrets. If secrets must be persisted in storage, either use a secure store or encrypt the values before storing them. Use SHA for one way hashing, or AES for values that must be decrypted again before use.

Do not store database connections, passwords, or keys in plaintext. Secrets that must be stored should be encrypted first. This can be done by encrypting values individually before storing them, or by using a protected configuration provider. Be aware that the ASP.NET RSA protected configuration provider relies upon a key pair for encryption. As mentioned above in Cryptography, key pairs cannot be safely installed in a Windows Azure VM due to the inability to delete the key pair deployment file.

Do not pass sensitive data using the HTTP-GET protocol. Data passed using HTTP-GET and HTTP-POST can easily be parsed and extracted. Due to the fact that HTTP-GET messages carry data on the querystring, they are particularly vulnerable to inadvertent copy-and-paste forwarding of data. If sensitive data is included on the querystring it can easily reach an attackers hands. Query strings are persisted in browser history, in proxy servers, and in web servers logs which makes it very easy to an attacker or dishonest system administrator to extract and reuse the data.

Design Guidelines Summary Hot Spot Description Auditing and Logging

Audit and log using Windows Azure Monitoring Data Service. Persist logs, and determine an archiving and backup strategy for logs.

Authentication Protect credentials, and consider the use of a claims based authentication system.

Authorization Secure all application resources. Recognize Windows Azure Storage and SQL Azure as additional resources, and protect them accordingly.

Communication Establish policies for certificate management. Be aware of potential injection vulnerabilities with RESTful interfaces.


Windows Azure has the portal for configuration management as well as any custom administration interfaces you might develop. Build policies around access.

Cryptography Certificates can be used as a means to deploy key pairs, determine an encryption strategy for configuration files and configuration stores.


Be aware of BLOB access and validate file uploads where possible. Defend against CSRF attacks, and sanitize output.

Exception Handle exceptions gracefully, be aware that more potential boundaries exist in a

Management Windows Azure application and ensure exceptions are handled at these boundaries.

Sensitive Data Avoid storing secrets. Establish an encryption strategy for secret stores.

Additional Considerations

Disaster Recovery When building your application, define and assess your needs for disaster recovery. It is important to know that the Windows Azure SLA requires at least 2 instances of a web or worker role to be active in order for the SLA to be in effect. This will ensure that your application remains functional and that the data is continuously available. However, the SLA does not cover scenarios in which the data is inadvertently corrupted due to errors in application code, or applications that fail due to mistakes made in deployment such as deploying the wrong version of code or buggy code. You disaster recovery plans should include processes for failover in the event of code errors, or data errors not covered by the SLA.

Business Continuity Planning Be sure to also evaluate your plans for Business Continuity Planning (BCP) when hosting applications on Windows Azure. Assuming the 2-instance minimum requirement is met, the SLA should ensure failover for failures within a data center. For systems requiring 100% up-time, it would be important to consider catastrophic failures such as a geographic data center being taken offline due to a calamity such as an earthquake. In this case your BCP should encompass failover to other geographically located data centers. This should be considered for both code and for data. If your separate data centers are Windows Azure data centers, the failover will be automatic.

Additional Resources • patterns & practices Improving Web Application Security – Threats and Countermeasures -

http://msdn.microsoft.com/en-us/library/ff649874.aspx • patterns & practices Security Guidance for Applications - http://msdn.microsoft.com/en-

us/library/ff650760.aspx • patterns & practices Web Client Guidance -

http://webclientguidance.codeplex.com/releases/view/46436 • Security Best Practices for Developing Windows Azure Applications at

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ff0c25f-dc54-4f56-aae7-481e67504df6 .

• Security Development Lifecycle - http://www.microsoft.com/security/sdl/







http://www.microsoft.com/security/sdl/�

Choosing Web Application Security Solutions

Objectives • Recognize which scenario best meets a set of given characteristics. • Understand benefits of each scenario. • Understand considerations of each scenario.

Overview Here we present each scenario and some distinguishing characteristics to help you align your situation to a particular solution. We also call out explicit benefits of the scenarios and considerations to be aware of.

Key Security Architectures The following application scenarios represent a set of common application implementations on the Windows Azure platform. • ASP.NET Forms Authentication to Azure Tables. This scenario represents the most basic

implementation of authentication in an ASP.NET web site by using the ASP.NET membership provider and roles provider system, and Windows Azure Storage.

• ASP.NET Forms Authentication to SQL Azure. This scenario uses the ASP.NET SqlMembershipProvider and SqlRoleProvider to implement authentication, and store user data in SQL Azure.

• ASP.NET to Active Directory with Claims. This scenario demonstrates using an existing Active Directory user store with a Windows Azure hosted ASP.NET application. This solution is based on WS* and uses Windows Identity Foundation, and ADFS2.

• ASP.NET to Active Directory with Claims (Federated Partner). This extends the claims scenario by federating identity with a partner. The partner identity store is coordinated with a federation provider.

Benefits and Considerations Matrix

ASP.NET Applications Scenario Benefits Considerations Forms Authentication to Windows Azure Storage

• Lower cost per megabyte storage ratio.

• Existing guidance is widely available.

• There is a cost per transaction basis that may grow only if there are extremely large numbers of transactions.

• Windows Azure Storage provides only 1 index per table, which limits the querying capability into the user store.

• At the time of this writing, the provider is a sample, and has not been rigorously tested like established providers like SqlMembershipProvider.

• Membership will pass credentials over wire when authenticating. They should be protected during communication by using SSL.

• If you update your authentication code, you will need to re-deploy the application.

Forms Authentication to SQL Azure

• Existing guidance is widely available.

• SQL providers ship with the .NET Framework and have been extensively tested.

• A large amount of product documentation and samples exist for SQL providers.

• User data stored in SQL Azure can be relational which makes it more flexible for use in other functions beyond authentication.

• There is no cost per transaction.

• Membership will pass credentials over wire when authenticating. They should be protected during communication by using SSL.

• Building a new user store will cause additional work for administrators when adding users to the system. This can be a bigger problem in large corporate environments due to the large number of systems that are managed.

• SQL Azure has database size limitations, which may force partitioning of user data across multiple databases.

• If you update your authentication code, you will need to re-deploy the application.

ASP.NET to AD with Claims

• You can leverage existing Active Directory user stores through Active Directory Federation Services (ADFS v2).

• This is an implementation of Single Sign-On.

• Uses security tokens instead of credentials, which is more secure because credentials are not passed over the network.

• Building around claims allows you to separate authentication logic from application logic.

• Corporate user store exposed to public Internet.

• Management of trust relationships between applications and Secure Token Services such as ADFS are a manual process. Corporate IT policies may require re-establishing trust relationships which would be manual.

• Tokens issued by ADFS can be used to access REST services protect by AppFabric Access Control.

ASP.NET to AD with Claims (Federated)

• You can leverage existing Active Directory user stores through Active Directory Federation Services (ADFS v2).

• This is an implementation of Single Sign-On.

• This is an implementation of federated identity.

• Uses security tokens instead of credentials, which is more secure because credentials are not passed over the network.

• Building around claims allows you to separate authentication logic from application logic.

• Corporate user store exposed to public Internet.

• Management of trust relationships between applications and Secure Token Services such as ADFS are a manual process. Corporate IT policies may require re-establishing trust relationships which would be manual.

Common Scenarios and Solutions

Forms Authentication to Azure Storage Use this scenario if: • You have an existing solution based on the ASP.NET membership system. • You do not have multiple applications that will need to share the same authentication logic. • You do not have authorization needs that extend beyond simple user names and

groups/roles. • You are metering expenditures for total storage size utilized, but not on number of

transactions. • You do not have a need to extract business intelligence from the user store.

Forms Authentication to SQL Azure Use this scenario if: • You have an existing solution based on the ASP.NET membership system. • You wish to leverage an existing established an tested authentication system. • You have a need to extract business intelligence from the user store. • You do not have multiple applications that will need to share the same authentication logic. • You do not have authorization needs that extend beyond simple user names and

groups/roles.

ASP.NET to Active Directory with Claims Use this scenario if: • You have an existing user store hosted in Active Directory. • Exposing the AD user store to the public internet via port 80 or 443 is permissible. • You are seeking a Single Sign-On (SSO) solution. • You have multiple applications that will need to share the same authentication logic. • You wish to isolate authentication logic from application code.

ASP.NET to AD with Claims, Federated Use this scenario if: • You have an existing user store hosted in Active Directory. • Exposing the AD user store to the public internet via port 80 or 443 is permissible. • You are seeking a Single Sign-On (SSO) solution. • You have multiple applications that will need to share the same authentication logic. • You wish to isolate authentication logic from application code.

Web Application Security Visual Scenarios

Objectives • Gain familiarity with a set of canonical web application scenarios • Understand a high-level solution to each scenario • Recognize key components required to solve each scenario

Overview This is a set of web application scenarios presented visually. We give you a baseline scenario to easily map to your application, and then present a solution overlay. We summarize the solution parts and overall approach.

Key Scenarios • ASP.NET Forms Authentication to Azure Tables • ASP.NET Forms Authentication to SQL Azure • ASP.NET to AD with Claims • ASP.NET to AD with Claims (“Federated Partner”)

ASP.NET Forms Authentication to Azure Tables

Scenario

Azure Environment

DataASP.NET

AppClient

Browser

Solution

Azure Environment

Web Role

ASP.NETApp

Forms AuthTableStorageMembershipProvider

SQL AzureAzure Tables

Role StoreUser Store

Azure StorageSSL

Private key access

controlled

TableStorageRoleProvider

Client Browser

Solution Summary Table Area Notes Authentication • Authenticate users with forms authentication.

• Store users in Azure Tables. • Use TableStorageMembershipProvider for membership API’s. • Authenticate application against Azure Storage with access key. • Map ASP.NET users to single Azure Storage connection. • Database access occurs as the application identity.

Authorization • Use TableStorageRoleProvider for roles API’s. • 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).

ASP.NET Forms Auth to SQL Azure

Scenario

Azure Environment

SQL AzureClient

BrowserASP.NET

App

Solution

Azure Environment

Web Role

ASP.NETApp

Forms AuthenticationSqlMembershipProvider

SQL Azure


SSL

Secure TDS Pipe

SqlRoleProvider

Client Browser

Solution Summary Table Area Notes Authentication • Authenticate users in ASP.NET application using forms

authentication. • Use SqlMembershipProvider for ASP.NET app authentication • Store users in SQL Azure. • Connect to SQL using the application identity. • Store SQL connection strings in web.config.

Authorization • Protect application resources based on roles. • Store roles in SQL Azure. • Use SqlRoleProvider for roles API’s. • Use SQL users and roles for authorization inside SQL Azure.

Communication • Use HTTP port 80 for non-secure connections to ASP.NET application.

• Perform forms authentication over port 443 (SSL). • Connect to SQL Azure over port 1433. • Use encrypted TDS for app to database communications. • Authenticate to SQL Azure over encrypted TDS. • Configure SQL Azure to filter connections based on IP address.

ASP.NET to AD with Claims

Scenario

On-Premises Azure Environment

ASP.Net AppClient Browser

AD

Solution


SQL

Web Role

ASP.NET AppClient

Browser


AD

Identity Provider (ADFS2)

SAML Token

SSL

WIF

TrustRelationship

Solution Summary Table Area Comments Authentication • Authenticate client browser against Active Directory Federation Services.

• Obtain user credentials as claims. • Use ADFS to provide claims. • Authenticate users in application using claims. • Use Windows Identity Foundation in ASP.NET app to manage SAML

tokens. Authorization • Authorize users against claims.

• Authorize in application logic. • Use on-site SQL Server for additional claims beyond what AD can provide.

Communication • Communicate claims using WS-* protocols. • Protect claims over the wire using Security Assertion Markup Language

(SAML). • Protect SAML tokens with SSL.

ASP.NET to AD with Claims (“Federated Partner”)

Scenario


ASP.Net AppClient Browser

AD

Solution


Web Role

ASP.Net AppClient

Browser

AD

Identity Provider

(ADFS2 STS)Federation Provider

(STS)

Web Role

Encrypted TDS Pipe

SQL Azure

App Data

Role Store

User Store

TrustRelationships

SAML Token

SSL

WIF

WIFPartner

Identity Provider (STS)

Solution Summary Table Area Comments

Authentication • Authenticate client browser against Active Directory. • Obtain user credentials as claims. • Use Active Directory Federation Services (ADFS) to provide claims. • Authenticate users in application using claims. • Corporate users obtain authentication token from Federation provider

web role using a claims token provided by ADFS v2 . • Store partner identities in SQL Azure. • Partner clients use Federation provider web role to obtain authentication

token. • Establish trust relationship between ASP.NET app and Azure hosted

Federation Provider Secure Token Service (STS). • Establish trust relationship between ADFS and Azure Federation Provider

STS. • Establish trust relationship between partner Identity Providers and Azure

Federation Provider STS. Authorization • Authorize users against claims.

• Authorize in application logic. • Use on-site SQL Server for additional claims beyond what AD can provide.

Communication • Communicate claims using WS-* protocols. • Protect claims over the wire using Security Assertion Markup Language

(SAML). • Protect SAML tokens with SSL.

Choosing Web Service Security Architectures



Key Security Architectures The following application scenarios represent a set of common application implementations on the Windows Azure platform involving web based services. • ASP.NET to WCF. This scenario illustrates Windows Azure hosting and ASP.NET application,

a WCF service and how to connect the two. It uses transport security and calls to the service are made as a single identity.

• ASP.NET On-Site to WCF on Windows Azure. In this scenario an ASP.NET application hosted on-site calls a WCF service hosted on Windows Azure using message security, and passing the identity of the original caller.

• ASP.NET to WCF with Claims. This scenario uses the Windows Identity Framework to connect an ASP.NET application to a WCF service while authenticating using claims in an authentication token, and maintaining the identity of the authenticated user.

• REST Service with AppFabric Access Control. In this scenario, a web service is implemented with a RESTful interface. To authenticate access to the REST service, the AppFabric Access Control is used to obtain a Simple Web Token (SWT). Access Control works in a trust relationship with an Identity Provider such as ADFS to issue Simple Web Tokens.

Benefits and Considerations Matrix Scenario Benefits Considerations ASP.NET to WCF • Service authentication requires

only the server-side X509 certificate.

• ASP.NET authentication is independent of WCF authentication.

• For best performance, you should take advantage of internal endpoints. To do this, you must package and deploy the client with the WCF service.

• To implement course-grained

authorization requires authorization logic at application level.

• Service is authenticated when it is registered in the client. The client is authenticated when it can sign the messages using the certificate delivered during registration.

• If you update your authentication code, you will need to re-deploy the service.

• If you wish to flow original caller identity, it must be done with custom code.

On-site ASP.NET to WCF on Windows Azure

• ASP.NET authentication is independent of WCF authentication.

• Username authentication for WCF service allows you to flow identity from the client to the WCF service.

• You can audit at the user level because the user name is provided in the username authentication.

• Uses one-way authentication of the service.

• If you update your authentication code, you will need to re-deploy the service.

ASP.NET to WCF with Claims

• Authentication logic can be updated independently of application code.

• Claims authorization allows for more fine grained authorization.

• Identity federation enables trust relationships between application and other domains or identity providers. Users log into their own domain prior to accessing the application.

• Can integrate with REST services because SAML claims tokens can be converted to Simple Web Tokens.

• Trust relationships are a manual process. This will require more management overhead.

• Application logic to build required SAML token to flow context is more complex. There are special considerations for deploying WIF-enabled services and for implementing identity federation at the ASP.NET application.

REST with AppFabric Access Control

• Supports claims based authorization scenarios.

• Can integrate with Active Directory.

• Enables federated identity scenarios for REST-based

• Active Directory support is achieved by converting SAML claims to SWT with AppFabric Access Control.

• This is the primary authentication story for Microsoft REST based services. Other approaches would

services. • Supports identity providers

such as ADFS or others that can issue SAML tokens.

be custom code. • Requires the use of AppFabric

Access Control which is a separate cost to a base Windows Azure subscription.


ASP.NET to WCF Use this scenario if: • You have an ASP.NET application that will connect to a WCF service. • You will be hosting both the ASP.NET application, and the WCF service in Windows Azure. • The ASP.NET application will be required to authorize access to the WCF service. • A common identity will be used for all WCF connections. • The WCF service does not need to uniquely identify individual connections.

On-site ASP.NET to WCF on Windows Azure Use this scenario if: • You have an existing ASP.NET application hosted on-site. • You will be hosting the WCF service in Windows Azure. • The original caller’s identity will be used to authenticate against the WCF service. • The WCF service needs to uniquely identify individual connections. • You require user level auditing at the WCF service level.

ASP.NET to WCF with Claims Use this scenario if: • Users will authenticate against the ASP.NET application using claims from a SAML token. • You have user claims provided by a Secure Token Service (STS). • You need to connect to the WCF service using a SAML token. • You wish to authenticate and authorize in the WCF service using claims. • The WCF service requires the claims/identity of the original caller.

REST Service with AppFabric Access Control Use this scenario if: • You have REST service hosted in Windows Azure. • You need to authenticate access to the REST service.

• You will authenticate and authorize within the REST service using claims. • You may have the need to leverage claims in SAML tokens.

Web Service Security Visual Scenarios

Objectives • Gain familiarity with a set of canonical web service scenarios. • Understand a high-level solution to each scenario. • Recognize key components required to solve each scenario.

Overview This is a set of visual scenarios for cloud hosted web services. We give you a baseline scenario to easily map to your application, and then present a solution overlay. We summarize the solution parts and overall approach.

Key Scenarios The following application scenarios represent a set of common application implementations on the Windows Azure platform involving web based services. • ASP.NET to WCF • ASP.NET On-Site to WCF on Windows Azure • ASP.NET to WCF with Claims • REST Service with AppFabric Access Control

ASP.NET to WCF

Scenario

Azure Environment

WCF ServiceASP.NET App

Solution

Azure Environment

Web Role

WCF(Web Service)

Service Auth

SSLASP.NET

App

Web Role

Proxy

Solution Summary Table Area Notes Authentication • Host WCF service in dedicated deployment package.

• Host ASP.NET application in separate deployment package. • Authenticate against service using server certificate. • Deliver service certificate during design/development of client ASP.NET

application. • Authenticate application under single application identity.

Authorization • Authorize service access in ASP.NET logic. Communication • Use Transport security to secure communication.

• Use X509 certificate for SSL encryption.

On-site ASP.NET to WCF on Windows Azure

Scenario

On-premises Azure Environment

ASP.NET App

WCF(Web

Service)

Solution

On-premises Azure Environment

Web Role

WCF(Web Service)

Username Auth

MessageEncryption

Web Server

ASP.NET App

Proxy

Solution Summary Table Area Notes Authentication • Application authenticated under application identity.

• Service authenticated with server cert. • Service certificate delivered during design/development. • Use WCF username security to flow user credentials from client app.

Authorization • Authorize users in logic implemented at ASP.NET level (trusted subsystem).

Communication • Use Message security to protect over the wire. • Encrypte messages with X509 server certificate. • Use X509 certificate to support SSL encryption.

ASP.NET to WCF with Claims

Scenario

Azure Environment

WCF ServiceASP.NET App

Solution

Azure Environment

Web Role

WCF Service

Identity Provider

STS

On-premises

Web Server

ASP.NET App

Proxy

Trust relationship

ActAs SAMLToken

Trust relationship

ws2007FederationHttpBinding

Solution Summary Table Area Notes Authentication • Establish trust relationship between application and STS.

• Establish trust relationship between WCF service and STS. • Obtain access token from an Identity Provider (STS - Simple Token

Service). • Obtain claims in access token. • Authenticate in ASP.NET application using claims as credentials. • Connect to WCF using the original caller identity. • Obtain impersonation token (ActAs token) from STS. • Use impersonation token to access WCF service.

Authorization • Authorize in WCF service against claims provided in token. Communication • Use HTTP for App->STS communication.

• Use HTTP for App->WCF communication. • Use HTTP for WCF->STS communication.

REST with ACS

Scenario

Azure Environment

REST ServiceApp Client

Solution

Azure Environment

Web Role

REST ServiceApp Client

oAuth ClaimsAuthenticated

AppFabric

TrustRelationship

SWT (Simple Web Token)

ACS

Solution Summary Table Authentication • Use AppFabric Access Control for authentication to REST service.

• Authenticate REST service using claims provided by Access Control. • Establish trust relationship between REST service and Access Control. • Create AppFabric service namespace for claims mapping. • Use client to obtain Simple Web Token (SWT) from Access Control. • Use SWT to authenticate connections to REST service.

Authorization • Authorize service resources against claims in SWT. Communication • Communicate with Access Control using oAuth WRAP (protocol).

• Use SWT to provide claims. • Send oAuth WRAP messages over HTTP.

Choosing Data Security Architectures



Key Security Architectures The following application scenarios represent a set of common application implementations on the Windows Azure platform involving data storage security. • ASP.NET to Azure Storage: This scenario demonstrates securing access to Windows Azure

Storage. It uses ASP.NET membership and roles, while mapping users to a single connection. • ASP.NET to SQL Azure: In this scenario we demonstrate SQL Azure access providing users

with differing levels privileges to the data by mapping them to set roles. • ASP.NET On-Site to Data on Azure through WCF: This scenario illustrates Data as a Service

by connecting an on-site application to data hosted in the cloud using WCF. • ASP.NET on Windows Azure to SQL Server On-site: In this scenario you have deployed an

ASP.NET application to Windows Azure, but the data lives on-site. A WCF service is used to expose the data, and the AppFabric Service Bus is used to expose the service through the corporate firewall to the Windows Azure Application.

Benefits and Considerations Matrix

Data Scenario Benefits Considerations ASP.NET to Azure Storage

• Lower cost per megabyte storage ratio.

• Forms authentication has extensive existing guidance available.

• Per-transaction cost is incurred. • Data is not relational, which limits

the ability to query against the data.

• Functionally, only 2 indexes per

table. • Authentication and authorization

should be implemented in application code because of only 1 data connection to Azure Storage.

ASP.NET to SQL Azure • Existing SQL Server logic is almost a direct port to SQL Azure.

• SQL Providers from ASP.NET have been extensively tested

• Data is relational. • Many existing SQL tools can be

used.

• SQL Azure has fixed database size increments. Large amounts of data may require data partitioning.

• SQL Connection should be protected by encrypting the TDS connection.

ASP.NET On-Site to Data on Windows Azure through WCF

• Can be used as a migration step for moving an application to cloud.

• Scenario is based around setting up Data as a Service (DaaS).

• On-site ASP.NET application may need to be deal with latency when receiving cloud data.

• Connections to WCF occur as service identity so authorization logic must be implemented in the application.

• To flow user identity through to WCF service, custom code is needed.

• Management of SQL credentials (password expiration, changes, etc) are a manual process.

ASP.NET on Windows Azure to

• Can be used as a migration step for moving an application to cloud.

• Exposes Data as a Service (Daas), which can lower the amount of code changes needed if data is moved to the cloud.

• Windows Azure ASP.NET application may need to be deal with latency when handling data hosted on-site.

• Connections to WCF occur as service identity so authorization logic must be implemented in the application.

• To flow user identity through to WCF service, custom code is needed.


ASP.NET to Azure Storage Use this scenario if: • You are metering expenditures on total storage size utilized. • Your data is not relational.

• Your data only needs to be accessed on 1 or 2 keys. • The data will not have a service interface for its front-end.

ASP.NET to SQL Azure Use this scenario if: • Your data is relational. • You have existing logic or investment in SQL Server. • You are metering expenditures on a per-transaction basis. • The data will not have a service interface for its front-end.

ASP.NET On-Site to Data on Windows Azure through WCF Use this scenario if: • You want to host your data in the cloud. • Your data is relational. • You have existing logic or investment in SQL Server. • Your user administration is on-site.

ASP.NET On-Site to Data on Windows Azure through WCF Use this scenario if: • You cannot move your data to the cloud. • You have restrictions in exposing your data to the public Internet. • Your data consumption needs to not require low latency.

Data Security Visual Scenarios

Objectives • Gain familiarity with a set of canonical data security scenarios. • Understand a high-level solution to each scenario. • Recognize key components required to solve each scenario.

Overview This is a set of visual scenarios for cloud hosted applications involving data storage. We give you a baseline scenario to easily map to your application, and then present a solution overlay. We summarize the solution parts and overall approach.

Key Scenarios • ASP.NET to Azure Storage • ASP.NET to SQL Azure • ASP.NET On-Site to Data on Azure through WCF • ASP.NET on Windows Azure to SQL Server On-Site

ASP.NET to Azure Storage

Scenario

Azure Environment

Azure Storage

ASP.Net AppBrowser

Solution

Azure Environment

Azure Storage

ASP.Net AppBrowser

Forms Authentication

Alice

Bob

Carol

Doug

Shared Key Encrypted Connection

Solution Summary Table Area Notes Authentication • Authenticate users with forms authentication.

• Store users in Azure Tables. • Use TableStorageMembershipProvider for membership API’s. • Authenticate application against Azure Storage with access key. • Map ASP.NET users to single Azure Storage connection.

Authorization • Use TableStorageRoleProvider for roles API’s. • Authorize users in application logic.

Communication • Use HTTP port 80 for non-secure connections to ASP.NET application. • Perform forms authentication over port 443 (SSL).

ASP.NET to SQL Azure

Scenario

Azure Environment

SQL AzureASP.Net

AppBrowser

Solution

Azure Environment

SQL AzureASP.Net

AppBrowser

SQL UsersSQL Roles

Forms Authentication

Alice

Bob

Carol

Doug

Encrypted TDS Pipe

App Data

Solution Summary Table Area Note Authentication • Authenticate users in ASP.NET application using forms authentication.

• Use SqlMembershipProvider for ASP.NET app authentication. • Map users to a single SQL user account. • Store SQL connection strings in web.config.

Authorization • Use SqlRoleProvider for roles API’s. • Use SQL users and roles for authorization inside SQL Azure.

Communication • Use HTTP port 80 for non-secure connections to ASP.NET application. • Perform forms authentication over port 443 (SSL). • Connect to SQL Azure over port 1433. • Use encrypted TDS for app to database communications. • Authenticate to SQL Azure over encrypted TDS. • Configure SQL Azure to filter connections based on IP address.

ASP.NET On-Site to Data on Azure through WCF

Scenario

Azure EnvironmentOn-Site

ASP.NET App SQL AzureService

Solution


Web Server

ASP.NET App

Web Role

SQL AzureWCF

Service

Alice

Bob

Carol

Doug

SSL

ProxySecure

TDS pipeService Auth

Solution Summary Table Area Comments Authentication • Authenticate users in ASP.NET using any method.

• Map users to single WCF connection. • Authenticate application against WCF using service authentication. • Deliver X509 certificate to client application at application design. • Authenticate against SQL Azure with common connection string. • Use common connection string for all data transactions.

Authorization • Implement authorization logic in ASP.NET application. • Map users to single WCF connection.

Communication • Use transport security to secure service communication. • Expose WCF endpoint on port 443 (SSL).

App Scenario: ASP.NET on Azure to SQL On-site

Scenario

Azure EnvironmentOn-Premises

ASP.NET AppWCF ServiceSQL

Solution


Web Role

ASP.NET App

Service Bus Alice

Bob

Carol

Doug

SQLServer 14

33

Web Server

WCF Service 44

3

Solution Summary Table Authentication • Authenticate users in ASP.NET using any method.

• Map users to single WCF connection. • Authenticate application against WCF using service authentication. • Deliver X509 certificate to client application at application design (on

service discovery). • Authenticate against SQL Azure with common connection string. • Use common connection string for all data transactions.

Authorization • Implement authorization logic in ASP.NET application. • Map users to single WCF connection.

Communication • Use transport security to secure service communication. • Expose WCF endpoint on port 443 (SSL).

What’s New with Windows Azure Development in Windows Azure is largely similar to development for an on-premise solution, but there are some important changes to recognize when designing and building your application. At a high level these can be summarized as:

• Limited/restricted access to the hosting Virtual Machine. • 2 Storage routes: Windows Azure Storage and SQL Azure • Authentication primarily through WS* protocols (federated authentication, SAML,

Secure Token Services (STS), and ADFS) • Changes to communication: IPs are dynamic, internal vs. external endpoints, IPC

through queues or internal endpoints The table below briefly outlines some important distinctions with some specific implementation details as well. Change Impact General • Because of dynamic IPs, use DNS names instead of IP addresses

• Design for stateless and loosely coupled systems, services, and data • Scope cookies to sub-domains, otherwise they will be shared across all

Azure applications • Cookie encryption should be compatible with web farms, change default

cookie encryption to RsaEncryptionCookieTransform Management portal

• Windows Azure management portal is restricted by Live ID. Control for distribution and management of Live ID’s will be required.

• Windows Azure portal provides Deployment API’s which provide alternate means of interfacing with the portal than the Web UI. Access is controlled by certificate authentication.

• Certificates are managed through the portal and must be rolled into the deployment process.

• Certificate management processes will need to be defined. Web Role • Exposes HTTP(S) endpoints to the Internet.

• Can expose other TCP ports to the Internet. • Port 80, 443 traffic is controlled by IIS.

Worker Role • Typically similar to Windows services, intended to run as background work processes.

• Can expose TCP ports called “Input Endpoints” to the Internet. Windows Azure Storage

• Access is controlled by a symmetric key. Access keys – Key management mechanism needed

• Windows Azure Storage access ultimately resolve to REST calls to Azure storage.

• Due to REST interfaces, data is transferred using HTTP or HTTPS as transport.

• BLOB storage has an alternate access key called Shared Access Signatures that grant temporary access to the BLOB.

• Windows Azure VM drives are hosted in Azure BLOB storage called Windows Azure Drives.

• Data can be accessed directly via RESTful interfaces, and may require data centric AuthN/AuthZ strategies to secure data.

• Throttling will happen if too many requests are made in a short time period. • Deploy your application to the same data center as your Windows Azure

storage for better performance. • Blobs, Entities, and Messages have different ways to locate and access

them. Blob partition keys are ContainerNam + BlobName. Enttity partition keys are TableName + PartitionKey. Message partition keys are QueueName. See Windows Azure Storage Abstractions and their Scalability Targets http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx

SQL Azure • SQL Azure provides SQL authentication only, no integrated security. • Application designs requiring granular authorization will need user

provisioning interfaces. • SQL Azure can restrict access by IP address via the SQL Azure firewall.

Beware of connectivity issues if the client IP is dynamic as in the cases of DHCP and proxies.

• Lack of user management (provisioning) integration with ADFS • SQL Azure firewall can permit service connections. This allows IPs inside of

the Azure domain to connect. • To avoid injection, avoid building connection strings using string

concatenation, use SqlConnectionStringBuilder class instead. • SQL Azure connections can be encrypted by using Encrypt=true connection

property. This forces authentication over SSL. • Use Persist Security Info=false. Setting Persist Security Info to true or yes

allows security-sensitive information, including the user ID and password, to be obtained from a connection after it has been opened.

• Throttling will happen if too many requests are made in a short time period. • Queries can time out if they take too long to execute.

AppFabric Access Control

• Access Control provides claims mapping. It can convert SAML tokens to SWT tokens.

• Configuration is through management portal. Live ID’s providing access should be managed.

• Tokens are signing by a shared key. Service cannot prove to a third party that a token was signed by AC and not by the service itself. Therefore you cannot achieve non-repudiation with AC issues tokens

http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx�

http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx�

• Token signing keys should be rolled over occasionally, requiring a rollover process.

AppFabric Service Bus

• Provides 3 forms of authentication; Shared Secret authentication, SAML authentication, SWT (Simple Web Token) authentication

• Service Bus based services are inherently discoverable. To allow access only through specific URI’s, set DiscoverType.Private on the ServiceRegistrySettings endpoint behavior.

Runtime Security (Code Access Security)

• 2 Windows Azure specific levels; Full Trust, and Windows Azure partial trust • Full Trust is default • Many permissions are blocked in Windows Azure, some key restrictions

include: Registry, Event Log, and Reflection. Full list can be found at: http://msdn.microsoft.com/en-us/library/dd573355.aspx


Checklist: Securing Windows Azure Applications

Architecture and Design Check Description □ The application authentication code has been removed from application code, and is

implemented separately. □ Instead of the application determining who the user is, identify the user by the claims

they provide. □ The design identifies permissions required by the application. □ The design verifies that required permissions do not exceed Windows Azure trust

policies. □ The design identifies storage requirements against storage options capabilities. □ The application doesn’t use explicit IP addresses, it uses friendly DNS names instead.

Deployment Considerations Check Description □ The design identifies operations that can be performed outside of the current data

center. □ The design groups application pieces in a single deployment package when they must

be hosted in the same data center. □ The application uses internal endpoints for tightly bound Inter-Process

Communications. □ The application uses Windows Azure Storage queues for loosely bound IPC. □ Application data is hosted in the same data center as the application components. □ The IT policies define distinct roles for parties associated with application

development, design, deployment, testing and management. □ The policies restrict roles from operations that exceed their defined responsibilities. □ Windows Azure Portal Live ID’s are not distributed to parties who do not perform

application administration. □ Deployment certificates are installed in the Windows Azure Portal for deployment

roles, and only distributed to parties responsible for application deployment.

Auditing and logging Check Description □ Audits and logs access is controlled by authentication and authorization mechanisms. □ Roles have been defined for access to audits and logs. □ The design considers how to flow caller identity across multiple tiers for auditing. □ The design identifies events to be logged across all layers and areas of functionality in

the application. □ All information to be logged in event logs or audits is processed using sanitization logic. □ The design identifies the storage, security, and analysis of the application log files.

Authentication Check Description □ Passwords are either encrypted or converted to a token before communication. □ The design identifies secure storage of credentials that are accepted from users. □ The design partitions the Web site into public and restricted areas using separate

folders. □ The design specifies criteria for a strong password, and enforces the password

requirements with code and policies. □ The design specifies criteria for a strong passphrases, and enforces the passphrase

requirements. □ The design establishes policies for account management. □ The design specifies a mechanism for locking bad accounts out. □ The application supports the disabling of an account, account lockout, and expiration. □ Password history (with salt) is stored in the user store for verification.

Authorization Check Description □ The application has additional security checks implemented after the initial

authentication process. □ The role design offers sufficient separation of privileges (the design considers

authorization granularity). □ Data creation, updating and deletion procedures exposed via RESTful interfaces are

authorized when possible. □ Data creation, updating and deletion procedures exposed via RESTful interfaces use

HTTP POST requests, not HTTP GET.

Communication Check Description □ Names used for Windows Azure Storage containers are not created directly from user

provided data, but first sanitized or hashed. □ Information communicated over the wires is either encrypted or protected in transport

with an encrypted protocol such as SSL.

□ Application management policies include procedures for managing encryption keys, including expiration and rotation.

□ Application management policies include procedures for managing Windows Azure Storage access keys, including expiration and rotation.

□ The application design specifies performance considerations for security decision points such as encryption strategies.

□ Outbound data is filtered for confidential information.

Configuration Management Check Description □ Administrator privileges are separated based on roles (for example, developer or

system administrator). □ Protected data that is segregated is accessed using a different access key than

unprotected data. □ Configuration secrets are not held in plain text in configuration files. □ Production data sources are not used for test environments, data connections specify

test data sources. □ Test data is manufactured, not a copy of live data. □ Administration interfaces are protected with strong authentication and authorization

logic.

Cryptography Check Description □ Platform-level cryptography is used and it has no custom implementations. □ Encryption keys are stored in a secure form or location, they are not stored in clear-

text, and key pair installation files are not left on the VM drive. □ Windows Azure Storage partition keys use values that are not hashed or encrypted. □ SQL Azure index columns use values that are not hashed or encrypted. □ One-way hashes use SHA encryption with a key length of 256-bit or larger. □ Symmetric encryption uses AES encryption with a key length of 256-bit larger. □ Asymmetric encryption and decryption uses RSA encryption with 2048-bit or larger

keys. □ Encryption keys used in the production environment are different from keys used in

non-production environments such as test. □ Encryption keys used in the production environment have been issued from a

Certificate Authority and are not self-signed certificates.

Exception Management Check Description □ The design outlines a standardized approach to structured exception handling across

the application. □ Application errors are logged to the error log. □ Application exception handling minimizes the information disclosure in case of an

exception. □ The design clearly defines which piece is responsible for handling exceptions at

application boundaries like service calls or IPC.

Input and Data Validation Check Description □ Data is validated for type, length, format, and range. □ The validation approach is to constrain, reject, and then sanitize input. (Looking for

known, valid, and safe input is much easier than looking for known malicious or dangerous input.)

□ User transactions are not automatically trusted as valid, first confirm that a form was delivered to the user with a token that has not been tampered with or reused.

□ The design identifies acceptable lifespans on Windows Azure Storage BLOB shared access signatures.

□ The application distributes shared access signatures over a secure channel like SSL. □ Output that contains user input or untrusted data is encoded using HtmlEncode and

UrlEncode. □ The design assumes that user input is malicious. □ Values sent from the client are processed with validation routines (this includes HTTP

headers, querystrings, and input values) □ The design applies defense in depth to the input validation strategy by providing input

validation across tiers.

Sensitive Data Check Description □ The design identifies protection mechanisms for sensitive data that is sent over the

network. □ Secrets are not stored unless necessary. (Alternate methods have been explored at

design time.) □ Secrets are not stored in code. □ Database connections, passwords, keys, or other secrets are not stored in plain text. □ Sensitive data is not transmitted with the GET protocol.

Visual Threats and Countermeasures for Web Applications

Objectives • Recognize key points of attack against cloud hosted web application scenarios. • Learn key vulnerabilities in a hosted web application. • Learn key countermeasures in cloud hosted web application scenarios.

Overview With an a visual understanding of the application scenarios, we now overlay threats, vulnerabilities and countermeasures on top of a canonical example of a scenario to call out specific points of attack and defense. Visually overlaying these components helps us understand the impact on our application designs.

Scenario

Azure Environment

Web Role

ASP.NETApp

Forms AuthTableStorageMembershipProvider

SQL AzureAzure Tables


Azure StorageSSL

Private key access

controlled

TableStorageRoleProvider

Client Browser

Threats / Attacks

Windows AzureWindows Azure

Client Browser

Web Role

ASP.NET App

Azure StorageForms AuthN

Roles AuthZ

Http SSL

Firewall

Unauthorized access to configuration stores

Encryption cracking

Man-in-the-middle

Man-in-the-middle

Privilege elevation

Session hijacking

Credential theft

Cookie replay Cookie manipulation

HTTP header manipulation

Data tamperingParameter manipulation

Disclosure of confidential dataUnauthorized access to administration

interfaces

Querystring manipulation

Firewall

Vulnerabilities


Client Browser

Web Role

ASP.NET App


Roles AuthZ

Firewall

Http SSL

Custom cryptography

Long-life encryption keys Unsecure key distribution

Unsecured encryption keys

Small encryption keys

Clear-text secretsUnauthenticated REST

Secrets in code

Clear-text credentials

Weak passwords

Relying on single gate-keeper

Clear-text configuration secrets Unencrypted REST

Firewall

Countermeasures


Client Browser

Web Role

ASP.NET App


Roles AuthZ

Http SSL

No clear-text credentials

Encrypt communication channels

Don’t store secrets

Strong password policy

Enforce separation of privileges

Consider granularity of access

Avoid proprietary cryptography Use multiple gate-keepers

Avoid exposing sensitive info to

web space

Secure session store

Authenticate and authorize session store access

Do not store credentials

Firewall

Firewall

Visual Threats and Countermeasures for Web Services

Objectives • Recognize key points of attack against cloud hosted web service scenarios • Learn key vulnerabilities in a hosted web service • Learn key countermeasures in cloud hosted web service scenarios

Overview With an a visual understanding of the application scenarios, we now overlay the threats, vulnerabilities and countermeasures on top of a canonical example of a scenario to call out specific points of attack and defense. Visually overlaying these components helps us understand the impact on our application designs.

Scenario

Windows Azure

Service Interface

Business

Data Access

Web Service

SQL Azure

Threats / Attacks

Windows Azure

Service Interface

Business

Data Access

Web Service

SQL Azure

Replay attack

Eavesdropping / Tampering

Brute force attack

Elevation of privilege

Dictionary attack

Unauthorized access

Denial of Service

Man-in-the-middle attack

SQL Injection

Vulnerabilities

Windows Azure

Service Interface

Business

Data Access

Web Service

SQL Azure

Insecure channel

Revealing sensitive data

Non-validated data used in SQL queries

Weak authorization

Concatenated connection strings or SQL commands

Insecure configuration stores

Failure to validate messages

Insecure channel

Failure to auditClear-text credentials

Countermeasures

Windows Azure

Service Interface

Business

Data Access

Web Service

SQL Azure

Message Validation

Transport or Message Security

Encryption

Authorization

Parameterized queries

Auditing/Logging


Encryption

Cheat Sheet - Web Application Security Threats and Countermeasures at a Glance Category Threats/Attacks Auditing and Logging

• User denies performing an operation. • Attacker exploits an application without trace. • Attacker covers his tracks. • Denial of Service – log saturation. • Disclosure of confidential information.

Authentication • Brute force attacks. • Cookie replay attacks. • Dictionary attacks. • Network eavesdropping. • Credential theft.

Authorization • Disclosure of confidential data. • Data tampering. • Elevation of privilege. • Luring attacks.


• Unauthorized access to configuration stores. • Retrieval of clear text configuration secrets. • Lack of individual accountability.

Cryptography • Encryption cracking. • Loss of decryption keys.


• Revealing sensitive system or application details. • Denial of service attacks.


• HTTP forgery (CSRF). • Cookie manipulation. • Query string manipulation. • HTTP header manipulation. • Cross-site scripting. • Buffer overflows. • SQL injection. • Canonicalization attacks. • Form field manipulation.

Sensitive Data • Accessing sensitive data in storage. • Network eavesdropping. • Information disclosure.

Session Management

• Session hijacking. • Session replay. • Man-in-the-middle attacks.

Vulnerabilities Category Vulnerabilities Auditing and Logging

• Failing to audit failed logons. • Failing to audit across application tiers.

Authentication • Azure Blobs - Secure Access Signature distribution over HTTP. • Azure Blobs – expired or bad Secure Access Signatures not

revoked. • Azure Blobs - Secure Access Signature lifetime too long. • Storing clear text credentials in configuration files. • Passing clear text credentials over the network. • Using weak passwords. • Permitting over-privileged accounts. • Permitting prolonged session lifetime. • Mixing personalization with authentication.

Authorization • Relying on a single gatekeeper. • Failing to limit database access to specified stored procedures. • Using inadequate separation of privileges.


• Using insecure configuration stores. • Storing clear text configuration data. • Using insecure administration interfaces. • Having too many administrators.

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.


• Failing to use structured exception handling. • Revealing too much information to the client.


• Insecure file upload to Windows Azure Storage BLOBs. • Using non-validated input in the Hypertext Markup Language

(HTML) output stream. • Failure to uniquely identify transactions.

• Failing to validate input from all sources including cookies,

query string parameters, HTTP headers, databases, and network resources.

• Using non-validated input used to generate SQL queries. • Relying on client-side validation. • Using input file names, URLs, or user names 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. Sensitive Data • Storing secrets in code.

• Storing secrets in clear text. • Storing secrets when you do not need to. • Passing sensitive data in clear text over networks.

Session Management

• Having insecure session state stores. • Permitting prolonged session lifetime. • Passing session identifiers over unencrypted channels. • Placing session identifiers in query strings.

Countermeasures Category Countermeasures 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. Authentication • Encrypt communication channels to secure authentication

tokens. • Use HTTPS only with forms authentication cookies. • Use authentication mechanisms that do not require clear text

credentials to be passed over the network. • Do not store credentials. • Use strong password policies. • Separate anonymous from authenticated pages.

Authorization • Use multiple gatekeepers. • Consider granularity of access. • Enforce separation of privileges. • Use least privilege accounts.


• Do not store credentials in clear text. • Avoid storing sensitive information in the Web space. • Use only local administration. • Use strong authentication and authorization on administrative

interfaces. 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

• Do not log private data such as passwords. • Do not reveal sensitive system or application information. • Use structured exception handling (by using try/catch blocks). • Catch and wrap exceptions only if the operation adds

value/information. Input and Data Validation

• Do not trust input. • Validate input: length, range, format, and type. • Constrain, reject, and sanitize input. • Encode output. • Uniquely identify transactions.

Sensitive Data • Do not store secrets in software. • Encrypt sensitive data over the network. • Secure the channel.

Session Management

• Secure the channel to the session store. • Authenticate and authorize access to the session store. • Partition site by anonymous, identified, and authenticated

users. • Reduce session timeouts. • Avoid storing sensitive data in session stores.

Cheat Sheet - Web Service (SOAP) Security Threats and Countermeasures at a Glance Category Threats/Attacks Auditing and Logging • Repudiation. An attacker denies performing an

operation, exploits an application without trace, or covers his or her tracks.












• Token stealing. An attacker steals the credentials or token of another user in order to gain authorization to resources or operations they would not otherwise be

able to access. Configuration Management



Exception Management • Information disclosure. Sensitive system or application details are revealed through exception information.



Impersonation/Delegation • Elevation of privilege. An attacker is able to run in the context of a higher-privileged user.

• Disclosure of confidential information. An attacker gains access to data that should only be available to another user.

Message Encryption • Failure to encrypt messages. An attacker is able to read message content off the network because it is not encrypted.



Message Replay Detection • Session replay. An attacker steals messages off the network and replays them in order to steal a user’s session.

Message Signing • Data tampering. An attacker modifies the data in a message in order to attack the client or the service.

Message Validation • Canonicalization attacks. Canonicalization attacks can occur anytime validation 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.








Session Management • Session hijacking. An attacker steals the session ID of another user in order to gain access to resources or operations they would not otherwise be able to access.

• Session replay. An attacker steals messages off the network and replays them in order to steal a user’s session.


• Inability to log out successfully. An application leaves a communication channel open rather than completely closing the connection and destroying any server objects in memory relating to the session.

• Cross-site request forgery. Cross-site request forgery (CSRF) is where an attacker tricks a user into performing an action on a site where the user actually

has a legitimate authorized account. • Session fixation. An attacker uses CSRF to set another

person’s session identifier and thus hijack the session after the attacker tricks a user into initiating it.

• Load balancing and session affinity. When sessions are transferred from one server to balance traffic among the various servers, an attacker can hijack the session during the handoff.

Vulnerabilities Category Vulnerabilities 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 • Broad distribution of Azure LiveID • Failure to roll-over certificates • Storing clear text credentials in configuration files.

• Using weak passwords. • 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 an untrusted network). Authorization • Relying on a single gatekeeper (e.g., relying on client-

side validation only). • Failing to limit database access to specified stored

procedures. • Using inadequate separation of privileges. • Connection pooling. • Permitting over-privileged accounts.


• 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 over-privileged process accounts and service

accounts. 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.

Impersonation/Delegation • Failure to revert to a lower privilege after using impersonation.

• Improper use of global impersonation across the entire service.

Message Encryption • Not encrypting messages. • Using custom cryptography. • Distributing keys insecurely. • Managing or storing keys insecurely

Message Replay Detection • Failure to use a mechanism to detect message replays. Message Signing • Not using either message or transport security. Message Validation • Using non-validated input used to generate SQL queries.

• Relying only on client-side validation. • Using input file names, URLs, or usernames for security


network resources. • Failing to validate input from all sources including

cookies, Simple Object Access Protocol (SOAP) headers, SOAP 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.

Session Management • Passing session IDs over unencrypted channels. • Permitting prolonged session lifetime. • Having insecure session state stores. • Placing session identifiers in query strings

Countermeasures Category Countermeasures 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.


• Encrypt sensitive sections of configuration files. • Use secure settings for various operations of Web

services using configuration files. 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.

Impersonation/Delegation • Use Using statement to automatically revert impersonation.

• Granularly impersonate only those operations that need it.

Message Encryption • Use message security or transport security to encrypt your messages.

• Use proven platform-provided cryptography.

• Periodically change your keys. Message Replay Detection • Use any platform-provided replay detection features.

• Consider creating custom code if the platform does not provide a detection mechanism.

Message Signing • Turn on message or transport security. Message Validation • Do not trust client input.

• 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. Sensitive Data • Do not store secrets in software.

• Encrypt sensitive data over the network. • Secure the channel. • Encrypt sensitive data in configuration files.

Session Management • Partition the site by anonymous, identified, and authenticated users.

• Reduce session timeouts. • Avoid storing sensitive data in session stores. • Secure the channel to the session store. • Authenticate and authorize access to the session store.

Cheat Sheet – Web Services (REST) Security Threats and Countermeasures at a Glance Category Threats/Attacks Auditing and Logging • Repudiation. An attacker denies performing an

operation, exploits an application without trace, or covers his or her tracks.












• Token stealing. An attacker steals the credentials or token of another user in order to gain authorization to resources or operations they would not otherwise be

able to access. Configuration Management



Exception Management • Information disclosure. Sensitive system or application details are revealed through exception information.



Impersonation/Delegation • Elevation of privilege. An attacker is able to run in the context of a higher-privileged user.

• Disclosure of confidential information. An attacker gains access to data that should only be available to another user.

Message Encryption • Failure to encrypt messages. An attacker is able to read message content off the network because it is not encrypted.



Message Replay Detection • Session replay. An attacker steals messages off the network and replays them in order to steal a user’s session.

Message Signing • Data tampering. An attacker modifies the data in a message in order to attack the client or the service.

Message Validation • Canonicalization attacks. Canonicalization attacks can occur anytime validation 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.








Session Management • Session hijacking. An attacker steals the session ID of another user in order to gain access to resources or operations they would not otherwise be able to access.

• Session replay. An attacker steals messages off the network and replays them in order to steal a user’s session.


• Inability to log out successfully. An application leaves a communication channel open rather than completely closing the connection and destroying any server objects in memory relating to the session.

• Cross-site request forgery. Cross-site request forgery (CSRF) is where an attacker tricks a user into performing an action on a site where the user actually

has a legitimate authorized account. • Session fixation. An attacker uses CSRF to set another

person’s session identifier and thus hijack the session after the attacker tricks a user into initiating it.

• Load balancing and session affinity. When sessions are transferred from one server to balance traffic among the various servers, an attacker can hijack the session during the handoff.

Vulnerabilities Category Vulnerabilities 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 • Failure to implement authentication on RESTful URI’s. • Storing clear text credentials in configuration files. • Using weak authentication mechanisms (e.g., using basic

authentication over an untrusted network).

• Using weak passwords. • Passing clear text credentials over the network. • Permitting prolonged session lifetime. • Mixing personalization with authentication.

Authorization • Failure to implement authorization on RESTful URI’s. • Improper design of REST interfaces • Relying on a single gatekeeper (e.g., relying on client-

side validation only). • Failing to limit database access to specified stored

procedures. • Using inadequate separation of privileges. • Permitting over privileged accounts.


• 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. 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.

Impersonation/Delegation • Failure to revert to a lower privilege after using impersonation.

• Improper use of global impersonation across the entire service.

Message Encryption • Sending private or sensitive information clear-text over HTTP.

• Using custom cryptography. • Distributing keys insecurely. • Managing or storing keys insecurely

Message Replay Detection • Failure to use a mechanism to detect message replays. Message Signing • Sending private or sensitive information clear-text over

HTTP Message Validation • Using non-validated input used to generate SQL queries.

• Relying only on client-side validation. • Using input file names, URLs, or usernames for security


network resources. • Failing to validate input from all sources including

cookies, Simple Object Access Protocol (SOAP) headers, SOAP parameters, databases, and network resources.

Sensitive Data • Sending private or sensitive information clear-text over HTTP

• 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.

Session Management • Passing session IDs over unencrypted channels. • Permitting prolonged session lifetime. • Having insecure session state stores. • Placing session identifiers in query strings

Countermeasures Category Countermeasures 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 authentication mechanisms that do not require clear text credentials to be passed over the network.

• Do not store credentials in an insecure manner. • Separate anonymous from authenticated pages. • Use strong password policies.

Authorization • Use multiple gatekeepers. • Tie authentication to authorization on the same tier. • Consider granularity of access. • Use least-privileged accounts. • Enforce separation of privileges.


• Authenticate and authorize access to administration interfaces.

• Encrypt sensitive sections of configuration files. • Use secure settings for various operations of Web

services using configuration files. 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.

Impersonation/Delegation • Use Using statement to automatically revert impersonation.

• Granularly impersonate only those operations that need it.

Message Encryption • Use message security or transport security to encrypt your messages.

• Use proven platform-provided cryptography. • Periodically change your keys.

Message Replay Detection • Use any platform-provided replay detection features. • Consider creating custom code if the platform does not

provide a detection mechanism. Message Signing • Turn on message or transport security. Message Validation • Validate input: length, range, format, and type.

• Constrain, reject, and sanitize input. • Validate XML streams. • Do not trust client input. • Encode output. • Restrict the size, length, and depth of parsed XML

messages. Sensitive Data • Do not store secrets in software.

• Encrypt sensitive data over the network. • Secure the channel. • Encrypt sensitive data in configuration files.

Session Management • Partition the site by anonymous, identified, and authenticated users.

• Reduce session timeouts. • Avoid storing sensitive data in session stores. • Secure the channel to the session store. • Authenticate and authorize access to the session store.

Cheat Sheet - Data Security Threats and Countermeasures at a Glance Category Threats/Attacks Auditing and Logging

• Repudiation • Denial of Service (DoS) • Disclosure of confidential information

Authentication • Azure Storage - Eavesdropping: Access to storage account endpoints (blob, table, and queue) over insecure communication channel (HTTP).

• Azure Blobs - Anonymous(public) access to Container/Blob. • Azure Blobs - Replay attack: reuse of shared access signature. • SQL Azure - Unauthorized access to SQL login credentials. • SQL Azure - Brute forcing login credentials. • SQL Azure - Connection re-authentication is not immediate if

login password is reset.

• Dictionary Attacks • Replay Attacks • Credential Theft • Network Eavesdropping • Brute Force Attacks

Authorization • SQL Azure - Using over privileged account (Admin account similar to SA) to connect to SQL Azure.

• Elevation of privilege • Disclosure of confidential data • Data tampering • Luring attacks • Token stealing


• Unauthorized access to storage account key. • Unauthorized access to Windows Azure Portal. • Unauthorized access to configuration stores. • Retrieval of clear text configuration secrets.

Cryptography • Encryption cracking. • Loss of decryption keys.


• Revealing sensitive system or application details. • Denial of Service attacks


• SQL Azure - Man-in-the-middle attack lack of SQL Azure certificate validation)

• HTTP Forgery (CSRF)

• Cookie manipulation • Query string manipulation • HTTP header manipulation • Cross-site Scripting (XSS) • Buffer overflows • SQL Injection • Form field manipulation

Sensitive Data • Accessing sensitive data in storage. • Network eavesdropping • Information disclosure

Session Management

• Session hijacking • Session replay • Man-in-the-middle attacks

Vulnerabilities Category Vulnerabilities Auditing and Logging

• Failing to audit failed logons • Failing to audit across application tiers

Authentication • Azure Blobs – Secure Access Signature distribution over HTTP. • Azure Blobs - Secure Access Signature failure to revoke. • Azure Blobs - Secure Access Signature failure to expire. • SQL Azure – lack of certificate validation. • SQL Azure – Failure to force re-authentication on login

password reset.

• Storing clear text credentials in configuration files. • Passing clear text credentials over the network. • Using weak passwords. • Permitting over-privileged accounts. • Permitting prolonged session lifetime. • Mixing personalization with authentication.

Authorization • SQL Azure - Using over privileged account (Admin account similar to SA) to connect to SQL Azure.

• Relying on a single gatekeeper. • Failing to limit database access to specified stored procedures. • Using inadequate separation of privileges.


• SQL Azure - Access Control: Not restricting access via SQL Azure Firewall.

• Azure Storage – Failure to secure storage account key. • Using insecure configuration stores.

• Storing clear text configuration data. • Using insecure administration interfaces. • Having too many administrators.

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.


• Failing to use structured exception handling. • Revealing too much information to the client.


• Azure Blobs - Insecure file upload to blob storage. • Using non-validated input in the Hypertext Markup Language

(HTML) output stream. • Failure to uniquely identify transactions.

• Failing to validate input from all sources including cookies,

query string parameters, HTTP headers, databases, and network resources.

• Using non-validated input used to generate SQL queries. • Relying on client-side validation. • Using input file names, URLs, or user names for security


network resources. Sensitive Data • Azure Storage – Communicating sensitive data over HTTP.

• Storing secrets in code. • Storing secrets in clear text. • Storing secrets when you do not need to. • Passing sensitive data in clear text over networks.

Session Management

• Having insecure session state stores. • Permitting prolonged session lifetime. • Passing session identifiers over unencrypted channels. • Placing session identifiers in query strings.

Countermeasures Category Countermeasures 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.

Authentication • Encrypt communication channels to secure authentication tokens.

• Use HTTPS only with forms authentication cookies. • Use authentication mechanisms that do not require clear text

credentials to be passed over the network. • Do not store credentials. • Use strong password policies. • Separate anonymous from authenticated pages.

Authorization • Use multiple gatekeepers. • Consider granularity of access. • Enforce separation of privileges. • Use least privilege accounts.


• Do not store credentials in clear text. • Avoid storing sensitive information in the Web space. • Use only local administration. • Use strong authentication and authorization on administrative

interfaces. 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.


• Do not log private data such as passwords. • Do not reveal sensitive system or application information. • Use structured exception handling (by using try/catch blocks). • Catch and wrap exceptions only if the operation adds

value/information. Input and Data Validation

• Do not trust input. • Validate input: length, range, format, and type. • Constrain, reject, and sanitize input. • Encode output. • Uniquely identify transactions.

Sensitive Data • Do not store secrets in software. • Encrypt sensitive data over the network. • Secure the channel.

Session Management

• Secure the channel to the session store. • Authenticate and authorize access to the session store. • Partition site by anonymous, identified, and authenticated

users.

• Reduce session timeouts. • Avoid storing sensitive data in session stores.

How To: Use Forms Authentication with Azure Table Storage

Objectives • Use the TableStorageMembershipProvider with forms authentication. • Set up the Table Storage membership data store. • Restrict the forms authentication cookie to HTTPS connections. • Use the membership feature to enforce password complexity rules.

Summary ASP.NET provides a membership feature that you can use with forms authentication. The membership feature provides an abstraction for the underlying data store used to maintain user credentials such as user names and passwords, and it provides an API that allows you to easily validate user credentials and manage the user data store. ASP.NET supports SQL Server and Active Directory providers, for this how to you would have to use your own providers for Azure Table Storage data store. This How To shows you how to develop a simple Web site that uses forms authentication with the Table Storage membership provider. This provider uses an underlying Table Storage Service as its user store.

Contents • Pre-Requisites • Summary of Steps • Step 1. Create a New Cloud Service Project. • Step 2. Add References to AspProvider Project for the Azure Table Storage Provider • Step 3. Add a Login Page • Step 4. Create a Way for New Users to Register • Step 5. Configure ASP.NET to use Forms Authentication • Step 6. Configure ASP.NET to Restrict Anonymous Users • Step 7. Configure ASP.NET to Use the Azure Table Storage Provider • Step 8. Configure the ASP.NET Membership Provider • Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details • Step 10. Test Registering a New User and Logging in to the Application

Pre-Requisites 1. Windows Azure SDK 2. Windows Azure Tools for Visual Studio 2008 3. Azure Samples – Additional C# Samples

http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=windowsazuresamples&DownloadId=8221�

Summary of Steps Here are the steps at a glance: • Step 1. Create a New Cloud Service Project. • Step 2. Add References to AspProvider Project for the Azure Table Storage Provider • Step 3. Add a Login Page • Step 4. Create a Way for New Users to Register • Step 5. Configure ASP.NET to use Forms Authentication • Step 6. Configure ASP.NET to Restrict Anonymous Users • Step 7. Configure ASP.NET to Use the Azure Table Storage Provider • Step 8. Configure the ASP.NET Membership Provider • Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details • Step 10. Test Registering a New User and Logging in to the Application

Step 1. Create a New Cloud Service Project. In this step, you create a new cloud service project in Visual Studio:

1. Start Visual Studio, from the menu select “File” then click “New’ and then click ‘Project” 2. In the “New Project’ dialog box, expand ‘Visual C#’ (or Visual Basic, if you are using it) in the

‘Project Types’ section, and select “Cloud Service”. 3. In the ‘Templates’ section choose “Windows Azure Cloud Service” template, set the

location, Name it as FormsAuthSample and click the “Ok” button. 4. In the “New Cloud Service Project” dialog box, select “ASP.NET Web Role”, and click the “>”

button to add it to the solution. Then click the “Ok” button. This will create a sample cloud Web Application, which is ready to be hosted in the cloud with all required configuration files etc.

5. Run and verify that it works fine.

Step 2. Add a Reference to the AspProvider Project for the Azure Table Storage Provider We didn’t see a Table Storage Membership provider for ASP.NET out of box, but there are samples available for download:

1. Unzip the WindowsAzure-AdditionalSamples.zip to some know location. You can find the Windows Azure Additional Samples on this page. (Note - if you followed my previous post, Getting Started with Windows Azure you should already have these samples.)

2. Right click on the ‘FormsAuthSample” solution and choose Add -> Existing Project 3. Browse to the location where you have extracted the samples, and select ASPProviders.proj

from \\Samples\AspProviders\Lib folder. This will add the ASPProviders project to your solution.

http://code.msdn.microsoft.com/windowsazuresamples�

http://code.msdn.microsoft.com/windowsazuresamples�

http://blogs.msdn.com/jmeier/archive/2010/03/16/getting-started-with-windows-azure.aspx�

4. Add the reference to this project to your solution. To do this, expand the WebRole1 node in the solution explorer, and right-click on References.

5. Select Add Reference 6. Select the Projects tab 7. Select AspProviders, and click “Ok”

Step 3. Add a Login Page. Use Solution Explorer to add a new Web form named Login.aspx to the WebRole1 site.

Step 4. Create a Way for New Users to Register Add the following two lines into the Login.aspx <form> tag <asp:Login runat="server" /> <asp:CreateUserWizard runat="server"></asp:CreateUserWizard> It should resemble the following: <form id="form1" runat="server"> <div> <asp:Login runat="server" /> <asp:CreateUserWizard runat="server"></asp:CreateUserWizard> </div> </form>

Step 5. Configure ASP.NET to use Forms Authentication In Web.config, add the following line inside the <system.web> tag: <authentication mode="Forms" />

Step 6. Configure ASP.NET to restrict Anonymous Users In Web.config, add the following line inside the <system.web> tag: <authorization> <deny users="?" /> <allow users="*" /> </authorization> Note – The preceding configuration allows only authenticated users to access the application. The "?" indicates unauthenticated users and the "*" indicates all users. By denying unauthenticated users, any requests made by unauthenticated users are redirected to the login page. The loginUrl attribute of the <forms> element determines the name of the login page. The default setting of this attribute is Login.aspx.

Step 7. Configure ASP.NET to Use the Azure Table Storage Provider In this step, you configure the Web application to use the AspProviders.TableStorageMembershipProvider.

In Web.config, add the following lines inside the <system.web> tag: <membership defaultProvider="TableStorageMembershipProvider" userIsOnlineTimeWindow = "20"> <providers> <clear/> <add name="TableStorageMembershipProvider" type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageMembershipProvider" applicationName="AspProvidersDemo" /> </providers> </membership>

Step 8. Configure the ASP.NET Membership Provider In Web.config, add the following code to the <appSettings> tag as follows: <appSettings>  <add key = "TableStorageEndpoint" value="http://127.0.0.1:10002/devstoreaccount1"/> <add key = "AccountName" value="devstoreaccount1"/> <add key = "AccountSharedKey" value="Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="/> </appSettings> Note: that we don’t have a lot of details on the AccountSharedKey, but we saw Jim Nakashima uses this value, so it’s good enough for now, until we know more.

Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details

1. Add a using statement to Default.aspx.cs in your WebRole1 project to add a reference to System.Web.Security.

2. Add the following code to Page Load of Default.aspx.cs in WebRole1:

protected void Page_Load(object sender, EventArgs e) { Response.Write("Hello, " + Server.HtmlEncode(User.Identity.Name)); FormsIdentity id = (FormsIdentity)User.Identity; FormsAuthenticationTicket ticket = id.Ticket; // optional - but if you use this add a reference to System.Web.Security Response.Write("<p/>TicketName: " + ticket.Name ); Response.Write("<br/>Cookie Path: " + ticket.CookiePath); Response.Write("<br/>Ticket Expiration: " + ticket.Expiration.ToString()); Response.Write("<br/>Expired: " + ticket.Expired.ToString()); Response.Write("<br/>Persistent: " + ticket.IsPersistent.ToString()); Response.Write("<br/>IssueDate: " + ticket.IssueDate.ToString()); Response.Write("<br/>UserData: " + ticket.UserData);

Response.Write("<br/>Version: " + ticket.Version.ToString()); }

Step 10. test registering a new user and logging in to the application

1. Run the project by using the F5 key (this runs the project in Debug mode.) 2. Create a new user. On your first visit, you need to create a new user (e.g. “bob”.) Note that

the password rules by default are alphanumeric plus one non-alphanumeric (for example, "password!")

3. Login to the application. Sign in with your new username and password pair.

The Web application should return something along the following lines:

Hello, bob TicketName: bob Cookie Path: / Ticket Expiration: 3/17/2010 3:04:40 PM Expired: False Persistent: False IssueDate: 3/17/2010 2:34:40 PM UserData: Version: 2

How To: Use Forms Authentication with Local SQL Membership

Objectives • Use the SqlMembershipProvider with forms authentication. • Set up the aspnetdb membership data store for local development. • Restrict the forms authentication cookie to HTTPS connections.

Summary ASP.NET provides a membership feature that you can use with forms authentication. The membership feature provides an abstraction for the underlying data store used to maintain user credentials such as user names and passwords, and it provides an API that allows you to easily validate user credentials and manage the user data store. ASP.NET supports SQL Server and Active Directory providers. This How To shows you how to develop a simple Web site that uses forms authentication with the SQL membership provider.

Contents • Pre-Requisites • Summary of Steps • Step 1. Create a New Cloud Service Project. • Step 2. Add a Login Page. • Step 3. Create a Way for New Users to Register • Step 4. Configure ASP.NET to use Forms Authentication • Step 5. Configure ASP.NET to restrict Anonymous Users • Step 6. Set up the SQL Membership Database • Step 7. Add the SQL Connection String • Step 8. Configure ASP.NET to Use the Azure Table Storage Provider • Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details • Step 10. test registering a new user and logging in to the application

Pre-Requisites 1. Windows Azure Tools for Visual Studio 2008 2. Microsoft SQL Server, or SQL Express with Standard or Mixed security model

Summary of Steps • Step 1. Create a New Cloud Service Project. • Step 2. Add a Login Page.

• Step 3. Create a Way for New Users to Register • Step 4. Configure ASP.NET to use Forms Authentication • Step 5. Configure ASP.NET to restrict Anonymous Users • Step 6. Set up the SQL Membership Database • Step 7. Add the SQL Connection String • Step 8. Configure ASP.NET to Use the Azure Table Storage Provider • Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details • Step 10. test registering a new user and logging in to the application

Step 1. Create a New Cloud Service Project. In this step, you create a new cloud service project in Visual Studio: 1. Start Visual Studio, from the menu select “File” then click “New’ and then click ‘Project” 2. In the “New Project’ dialog box, expand ‘Visual C#’ (or Visual Basic, if you are using it) in the

‘Project Types’ section, and select “Cloud Service”. 3. In the ‘Templates’ section choose “Windows Azure Cloud Service” template, set the

location, Name it as FormsAuthSample and click the “Ok” button. 4. In the “New Cloud Service Project” dialog box, select “ASP.NET Web Role”, and click the “>”

button to add it to the solution. Then click the “Ok” button. This will create a sample cloud Web Application, which is ready to be hosted in the cloud with all required configuration files etc.

5. Run and verify that it works fine.

Step 2. Add a Login Page. Use Solution Explorer to add a new Web form named Login.aspx to the WebRole1 site.

Step 3. Create a Way for New Users to Register Add the following two lines into the Login.aspx <form> tag <asp:Login runat="server" /> <asp:CreateUserWizard runat="server" /> It should resemble the following: <form id="form1" runat="server"> <div> <asp:Login runat="server" /> <asp:CreateUserWizard runat="server" /> </div> </form>

Step 4. Configure ASP.NET to use Forms Authentication In Web.config, add the following line insde the <system.web> tag:

<authentication mode="Forms" />

Step 5. Configure ASP.NET to restrict Anonymous Users In Web.config, add the following line inside the <system.web> tag: <authorization> <deny users="?" /> <allow users="*" /> </authorization> Note – The preceding configuration allows only authenticated users to access the application. The "?" indicates unauthenticated users and the "*" indicates all users. By denying unauthenticated users, any requests made by unauthenticated users are redirected to the login page. The loginUrl attribute of the <forms> element determines the name of the login page. The default setting of this attribute is Login.aspx.

Step 6. Set up the SQL Membership Database In this step, you configure the SQL data store for membership. This is accomplished through the use of the aspnet_regsql.exe utility. Details on aspnet_regsql.exe can be found at: http://msdn.microsoft.com/en-us/library/ms229862(VS.80).aspx Note: Configuring SQL Azure for use with ASP.NET membership providers requires some alternate steps. These can be found at: http://support.microsoft.com/kb/2006191

Step 7. Add the SQL Connection String In Web.config, add the connection string to the connectionStrings tag using the <add> tag as follows: <connectionStrings> <add name="MyLocalSQLServer" connectionString="Initial Catalog=aspnetdb;Data Source=MyServerName;Integrated Security=SSPI"/> </connectionStrings>

Step 8. Configure ASP.NET to Use the Azure Table Storage Provider In this step, you configure the Web application to use the AspProviders.TableStorageMembershipProvider. In Web.config, add the following lines inside the <system.web> tag: <membership defaultProvider="MySqlMembershipProvider" >

http://msdn.microsoft.com/en-us/library/ms229862(VS.80).aspx�

http://support.microsoft.com/kb/2006191�

<providers> <clear/> <add name="MySqlMembershipProvider" connectionStringName="MyLocalSQLServer" applicationName="MyAppName" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </membership>

Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details Add a using statement to Default.aspx.cs in your WebRole1 project to add a reference to System.Web.Security. Add the following code to Page Load of Default.aspx.cs in WebRole1: protected void Page_Load(object sender, EventArgs e) { Response.Write("Hello, " + Server.HtmlEncode(User.Identity.Name) + "<br />"); }

Step 10. test registering a new user and logging in to the application

1. Run the project by using the F5 key (this runs the project in Debug mode.) 2. Create a new user. On your first visit, you need to create a new user (e.g. “bob”.) Note

that the password rules by default are alphanumeric plus one non- alphanumeric (for example, "password!")

3. Login to the application. Sign in with your new username and password pair. 4. The Web application should return something along the following lines:

Hello, waldo

How To: Enable SSL with a Self-Signed Certificate on Windows Azure

Objectives - Create a self-signed certificate to be used to encrypt an SSL channel - Upload a certificate to Windows Azure using the Windows Azure Management portal - Enable an HTTPS endpoint on a Windows Azure web role

Summary Enabling SSL on a Windows Azure web role involves a few easy configuration steps, and deployment of a certificate. HTTPS must be enabled on the web role as an endpoint, the certificate must be associated with that endpoint, and the certificate must also be uploaded to Windows Azure. This how to provides steps on completing these tasks and enabling SSL on a web role.

Contents - Pre-requisites - Summary of Steps - Step 1 - Create and Install cert - Step 2 - Create VS project - Step 3 - Upload the certificate to Windows Azure Management portal - Step 4 - Publish the project to Windows Azure - Step 5 - Test the SSL

Prerequisites 1. Windows Azure SDK 2. Windows Azure Tools for Visual Studio 2008 3.

Summary of Steps - Step 1 - Create and Install cert - Step 2 - Create VS project - Step 3 - Upload the certificate to Windows Azure Management portal - Step 4 - Publish the project to Windows Azure - Step 5 - Test the SSL

Step 1 - Create and Install cert In this step we will use makecert.exe to create a self-signed test certificate. We will then convert that certificate to .PFX format such that it can be uploaded to Windows Azure. 1. Open a Visual Studio command prompt 2. Change your active directory to the location where you wish to place your certificate files. 3. Enter the following 2 commands: makecert -r -pe -n "CN=AzureSSL" -sky 1 "azuressl.cer" -sv "azuressl.pvk" -ss My pvk2pfx -pvk "azuressl.pvk" -spc "azuressl.cer" -pfx "azuressl.pfx" -pi password1 The first command creates the certificate and installs it in the certificate store under the current user’s personal certificates. This allows you to select the certificate from the Visual Studio UI.

Step 2 - Create VS project In this step we will create a bare-bones test project containing the web role we will enable SSL for. After creating the project we enable the SSL endpoint and attach the certificate to that endpoint. 1. File, New Project 2. Select "Cloud" from "Installed Templates" list on left 3. Type "AzureSSL" for name, and hit OK 4. Select Web Role from the left, and ">" to add to solution 5. Click OK 6. Right-click \Solution\AzureSSL\Roles\WebRole1, and select "Properties" 7. Select "Certificates" tab on left 8. Click "Add Certificate" button on top bar 9. Change "Store Location" drop-down to "CurrentUser" 10. Click "..." button under Thumbprint 11. Select AzureSSL cert from list and click OK 12. Select "Endpoints" tab on left 13. Enable the "HTTPS:" checkbox 14. Select "Certificate1" from the SSL certificate name drop-down

Step 3 - Upload the certificate to Windows Azure Management portal In this step we will upload the test certificate to Windows Azure. This step must be done before publishing our test project or an error will occur on deployment of the Visual Studio project because it will attempt to reference a certificate that does not exist.

1. Open http://windows.azure.com 2. Select the Service you will deploy to, or create one if necessary 3. At the bottom of the management page, find the Certificates area, and click the "Manage"

link on the right 4. Hit the "browse" button and select the PFX file created in step 1 5. Enter "password1" and confirm it in the password textboxes 6. Click "Upload"

Step 4 - Publish the project to Windows Azure In this step we will deploy our project and enable it for testing.

1. In your Visual Studio project from step 2, right click \Solution\AzureSSL and select "Publish"

2. In the Windows Explorer window that pops up, copy the path to the directory displayed into the clipboard

3. Switch to your browser with the Windows Azure Management portal open 4. If you are still in the manage certificates screen, return to the service management

screen 5. Click the "Deploy" button 6. Under "Application Package" area, select the "Browse" button 7. In file open dialog that pops up, paste the path from your clipboard to navigate to your

VS package 8. Select the AzureSSL.cspkg, and click "Open" 9. Under the "Configuration Settings" area, select the "Browse" button 10. Select the ServiceConfiguration.cscfg file, and click "Open" 11. At the bottom of the Deploy screen, enter AzureSSL in the textbox 12. Click "Deploy" 13. When the deployment completes, click the "Run" button

Step 5 - Test the SSL In this step we access our test project and validate that the page can be delivered using SSL.

1. Once the Web Role has completed initializing, click on the "Web Site URL" link 2. Change the URL scheme to HTTPS (in other words change http to https), and open the

page Browser behaviour will vary here, but most likely you will receive a warning about the certificate being for a different site, or not being from a trusted source. If you permit access to the site, the page will render empty and you browser should indicate that the page was delivered over SSL with a lock icon or something similar.

windows azure security notes (pdf) - microsoft · azure security notes ... our goal is to show how...

Documents