OWASP - User contributions [en]

Choosing and Using Security Questions Cheat Sheet

2013-07-25T10:01:15Z

Shane Argo: Fixed spelling error.

= Introduction =

This cheat sheet provides some best practice for developers to follow when choosing and using security questions to implement a "forgot password" web application feature. 

= The Problem =

There is no industry standard either for providing guidance to users or developers when using or implementing a Forgot Password feature. The result is that developers generally pick a set of dubious questions and implement them insecurely. They do so, not only at the risk to their users, but also--because of potential liability issues--at the risk to their organization. Ideally, passwords would be dead, or at least less important in the sense that they make up only one of several multi-factor authentication mechanisms, but the truth is that we probably are stuck with passwords just like we are stuck with Cobol. So with that in mind, what can we do to make the Forgot Password solution as palatable as possible?

= Choosing Security Questions and/or Identity Data =

Most of us can instantly spot a bad "security question" when we see one. You know the ones we mean. Ones like "What is your favorite color?" are obviously bad. But as the [[http://goodsecurityquestions.com/ Good Security Questions]] web site rightly points out,
"there really are NO GOOD security questions; only fair or bad questions".

The reason that most organizations allow users to reset their own forgotten passwords is not because of security, but rather to reduce their own costs by reducing their volume of calls to their help desks. It's the classic convenience vs. security trade-off, and in this case, convenience (both to the organization in terms of reduced costs and to the user in terms of simpler, self-service) almost always wins out.

So given that the business aspect of lower cost generally wins out, what can we do to at least raise the bar a bit?

Here are some suggestions. Note that we intentionally avoid recommending specific security questions. To do so likely would be counterproductive because many developers would simply use those questions without much thinking and adversaries would immediately start harvesting that data from various social networks.

== Desired Characteristics ==

Any security questions or identity information presented to users to reset forgotten passwords should ideally have the following four characteristics:

# '''Memorable''': If users can't remember their answers to their security questions, you have achieved nothing.
# '''Consistent''': The user's answers should not change over time. For instance, asking "What is the name of your significant other?" may have a different answer 5 years from now.
# '''Nearly universal''': The security questions should apply to a wide an audience of possible.
# '''Safe''': The answers to security questions should not be something that is easily guessed, or research (e.g., something that is matter of public record).

== Steps ==

=== Step 1) Decide on Identity Data vs Canned Questions vs. User-Created Questions ===

Generally, a single HTML form should be used to collect all of the inputs to be used for later password resets.

If your organization has a business relationship with users, you probably have collected some sort of additional information from your users when they registered with your web site. Such information includes, but is not limited to:

* email address
* last name
* date of birth
* account number
* customer number
* last 4 of social security number
* zip code for address on file
* street number for address on file

For enhanced security, you may wish to consider asking the user for their email address first and then send an email that takes them to a private page that requests the other 2 (or more) identity factors. That way the email itself isn’t that useful because they still have to answer a bunch of ‘secret’ questions after they get to the landing page.

On the other hand, if you host a web site that targets the general public, such as social networking sites, free email sites, news sites, photo sharing sites, etc., then you likely to not have this identity information and will need to use some sort of the ubiquitous "security questions". However, also be sure that you collect some means to send the password reset information to some out-of-band side-channel, such as a (different) email address, an SMS texting number, etc.

Believe it or not, there is a certain merit to allow your users to select from a set of several "canned" questions. We generally ask users to fill out the security questions as part of completing their initial user profile and often that is the very time that the user is in a hurry; they just wish to register and get about using your site. If we ask users to create their own question(s) instead, they then generally do so under some amount of duress, and thus may be more likely to come up with extremely poor questions.

However, there is also some strong rationale to requiring users to create their own question(s), or at least one such question. The prevailing legal opinion seems to be if we provide some sort of reasonable guidance to users in creating their own questions and then insist on them doing so, at least some of the potential liabilities are transferred from our organizations to the users. In such cases, if user accounts get hacked because of their weak security questions (e.g., "What is my favorite ice cream flavor?", etc.) then the thought is that they only have themselves to blame and thus our organizations are less likely to get sued.

Since OWASP recommends in the [[Forgot Password Cheat Sheet]] that multiple security questions should be posed to the user and successfully answered before allowing a password reset, a good practice might be to require the user to select 1 or 2 questions from a set of canned questions as well as to create (a different) one of their own and then require they answer one of their selected canned questions as well as their own question.

=== Step 2) Review Any Canned Questions with Your Legal Department or Privacy Officer ===

While most developers would generally first review any potential questions with whatever relevant business unit, it may not occur to them to review the questions with their legal department or chief privacy officer. However, this is advisable because their may be applicable laws or regulatory / compliance issues to which the questions must adhere. For example, in the telecommunications industry, the FCC's Customer Proprietary Network Information (CPNI) regulations prohibit asking customers security questions that involve "personal information", so questions such as "In what city were you born?" are generally not allowed.

=== Step 3) Insist on a Minimal Length for the Answers ===

Even if you pose decent security questions, because users generally dislike putting a whole lot of forethought into answering the questions, they often will just answer with something short. Answering with a short expletive is not uncommon, nor is answering with something like "xxx" or "1234". If you tell the user that they ''should'' answer with a phrase or sentence and tell them that there is some minimal length to an acceptable answer (say 10 or 12 characters), you generally will get answers that are somewhat more resistant to guessing.

=== Step 4) Consider How To Securely Store the Questions and Answers ===

There are two aspects to this...storing the questions and storing the answers. Obviously, the questions must be presented to the user, so the options there are store them as plaintext or as reversible ciphertext. The answers technically do not need to be ever viewed by any human so they could be stored using a secure cryptographic hash (although in principle, I am aware of some help desks that utilize the both the questions and answers for password reset and they insist on being able to ''read'' the answers rather than having to type them in; YMMV). Either way, we would always recommend at least encrypting the answers rather than storing them as plaintext. This is especially true for answers to the "create your own question" type as users will sometimes pose a question that potentially has a sensitive answer (e.g., "What is my bank account # that I share with my wife?").

So the main question is whether or not you should store the questions as plaintext or reversible ciphertext. Admittedly, we are a bit biased, but for the "create your own question" types at least, we recommend that such questions be encrypted. This is because if they are encrypted, it makes it much less likely that your company will be sued if you have some bored, rogue DBAs pursuing the DB where the security questions and answers are stored in an attempt to amuse themselves and stumble upon something sensitive or perhaps embarrassing.

In addition, if you explain to your customers that you are encrypting their questions and hashing their answers, they might feel safer about asking some questions that while potentially embarrassing, might be a bit more secure. (Use your imagination. Do we need to spell it out for you? Really???)

=== Step 5) Periodically Have Your Users Review their Questions ===

Many companies often ask their users to update their user profiles to make sure contact information such as email addresses, street address, etc. is still up-to-date. Use that opportunity to have your users review their security questions. (Hopefully, at that time, they will be in a bit less of a rush, and may use the opportunity to select better questions.) If you had chosen to encrypt rather than hash their answers, you can also display their corresponding security answers at that time.

If you keep statistics on how many times the respective questions has been posed to someone as part of a Forgot Password flow (recommended), it would be advisable to also display that information. (For instance, if against your advice, they created a question such as "What is my favorite hobby?" and see that it had been presented 113 times and they think they might have only reset their password 5 times, it would probably be advisable to change that security question and probably their password as well.)

=== Step 6) Authenticate Requests to Change Questions ===

Many web sites properly authenticate change password requests simply by requesting the current password along with the desired new password. If the user cannot provide the correct current password, the request to change the password is ignored. The same authentication control should be in place when changing security questions. The user should be required to provide the correct password along with their new security questions & answers. If the user cannot provide the correct password, then the request to change the security questions should be ignored. This control prevents both Cross-Site Request Forgery attacks, as well as changes made by attackers who have taken control over a users workstation or authenticated application session.

= Using Security Questions =

Requiring users to answer security questions is most frequently done under two quite different scenarios:
* As a means for users to reset forgotten passwords. (See [[Forgot Password Cheat Sheet]].)
* As an additional means of corroborating evidence used for authentication.

If at anytime you intend for your users to answer security questions for both of these scenarios, it is ''strongly'' recommended that you use two different sets of questions / answers.

It should noted that using a security question / answer in addition to using passwords does '''''not''''' give you multi-factor authentication because both of these fall under the category of "what you know". Hence they are two of the ''same'' factor, which is not multi-factor. Furthermore, it should be noted that while passwords are a very weak form of authentication, answering security questions are generally is a much weaker form. This is because when we have users create passwords, we generally test the candidate password against some password complexity rules (e.g., minimal length > 10 characters; must have at least one alphabetic, one numeric, and one special character; etc.); we usually do no such thing for security answers (except for perhaps some minimal length requirement). Thus good passwords generally will have much more entropy than answers to security questions, often by several orders of magnitude.

=== Security Questions Used To Reset Forgotten Passwords ===

The [[Forgot Password Cheat Sheet]] already details pretty much everything that you need to know as a developer when ''collecting'' answers to security questions. However, it provides no guidance about how to assist the user in selecting security questions (if chosen from a list of candidate questions) or writing their own security questions / answers. Indeed, the [[Forgot Password Cheat Sheet]] makes the assumption that one can actually use additional ''identity'' data as the security questions / answers. However, often this is not the case as the user has never (or won't) volunteer it or is it prohibited for compliance reasons with certain regulations (e.g., as in the case of telecommunications companies and [[http://en.wikipedia.org/wiki/Customer_proprietary_network_information CPNI]] data).

Therefore, at least some development teams will be faced with collecting more generic security questions and answers from their users. If you must do this as a developer, it is good practice to:
* briefly describe the importance of selecting a good security question / answer.
* provide some guidance, along with some examples, of what constitutes bad vs. fair security questions.

You may wish to refer your users to the [[http://goodsecurityquestions.com/ Good Security Questions]] web site for the latter.

Furthermore, since adversaries will try the "forgot password" reset flow to reset a user's password (especially if they have compromised the side-channel, such as user's email account or their mobile device where they receive SMS text messages), is a good practice to minimize unintended and unauthorized information disclosure of the security questions. This may mean that you require the user to answer one security question before displaying any subsequent questions to be answered. In this manner, it does not allow an adversary an opportunity to research all the questions at once. Note however that this is contrary to the advice given on the [[Forgot Password Cheat Sheet]] and it may also be perceived as not being user-friendly by your sponsoring business unit, so again YMMV.

Lastly, you should consider whether or not you should treat the security questions that a user will type in as a "password" type or simply as regular "text" input. The former can prevent shoulder-surfing attacks, but also cause more typos, so there is a trade-off. Perhaps the best advice is to give the user a choice; hide the text by treating it as "password" input type by default, but all the user to check a box that would display their security answers as clear text when checked.

=== Security Questions As An Additional Means Of Authenticating ===

First, it bears repeating again...if passwords are considered weak authentication, than using security questions are even less so. Furthermore, they are no substitute for true multi-factor authentication, or stronger forms of authentication such as authentication using one-time passwords or involving side-channel communications. In a word, very little is gained by using security questions in this context. But, if you must...keep these things in mind:

* Display the security question(s) on a separate page only ''after'' your users have successfully authenticated with their usernames / passwords (rather than only after they have entered their username). In this manner, you at least do not allow an adversary to view and research the security questions unless they also know the user's current password.
* If you also use security questions to reset a user's password, then you should use a ''different'' set of security questions for an additional means of authenticating.
* Security questions used for actual authentication purposes should regularly expire much like passwords. Periodically make the user choose new security questions and answers.
* If you use answers to security questions as a ''subsequent'' authentication mechanism (say to enter a more sensitive area of your web site), make sure that you keep the session idle time out very low...say less than 5 minutes or so, or that you also require the user to first re-authenticate with their password and then immediately after answer the security question(s).

= Related Articles =
[[Forgot Password Cheat Sheet]] 
[[http://goodsecurityquestions.com/ Good Security Questions web site]]

= Authors and Primary Editors =

Kevin Wall - kevin.w.wall[at]gmail com

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Attack Surface Analysis Cheat Sheet

2013-07-25T08:03:02Z

Shane Argo: Fixed spelling error.

= What is Attack Surface Analysis and Why is it Important? =

This article describes a simple and pragmatic way of doing Attack Surface Analysis and managing an application's Attack Surface. It is targeted to be used by developers to understand and manage application security risks as they design and change an application, as well as by application security specialists doing a security risk assessment. The focus here is on protecting an application from external attack - it does not take into account attacks on the users or operators of the system (e.g. malware injection, social engineering attacks), and there is less focus on insider threats, although the principles remain the same. The internal attack surface is likely to be different to the external attack surface and some users may have a lot of access.

Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective.

Attack Surface Analysis is usually done by security architects and pen testers. But developers should understand and monitor the Attack Surface as they design and build and change a system.

Attack Surface Analysis helps you to:
# identify what functions and what parts of the system you need to review/test for security vulnerabilities
# identify high risk areas of code that require defense-in-depth protection - what parts of the system that you need to defend
# identify when you have changed the attack surface and need to do some kind of threat assessment

= Defining the Attack Surface of an Application =

The Attack Surface describes all of the different points where an attacker could get into a system, and where they could get data out.

The Attack Surface of an application is:
# the sum of all paths for data/commands into and out of the application, and
# the code that protects these paths (including resource connection and authentication, authorization, activity logging, data validation and encoding), and
# all valuable data used in the application, including secrets and keys, intellectual property, critical business data, personal data and PII, and
# the code that protects these data (including encryption and checksums, access auditing, and data integrity and operational security controls).

You overlay this model with the different types of users - roles, privilege levels - that can access the system (whether authorized or not). Complexity increases with the number of different types of users. But it is important to focus especially on the two extremes: unauthenticated, anonymous users and highly privileged admin users (e.g. database administrators, system administrators).

Group each type of attack point into buckets based on risk (external-facing or internal-facing), purpose, implementation, design and technology. You can then count the number of attack points of each type, then choose some cases for each type, and focus your review/assessment on those cases.

With this approach, you don't need to understand every endpoint in order to understand the Attack Surface and the potential risk profile of a system. Instead, you can count the different general type of endpoints and the number of points of each type. With this you can budget what it will take to assess risk at scale, and you can tell when the risk profile of an application has significantly changed.

= Identifying and Mapping the Attack Surface =

You can start building a baseline description of the Attack Surface in a picture and notes. Spend a few hours reviewing design and architecture documents from an attacker's perspective. Read through the source code and identify different points of entry/exit:
* User interface (UI) forms and fields
* HTTP headers and cookies
* APIs
* Files
* Databases
* Other local storage
* Email or other kinds of messages
* Run-time arguments
* …. [your points of entry/exit]

The total number of different attack points can easily add up into the thousands or more. To make this manageable, break the model into different types based on function, design and technology:
* Login/authentication entry points
* Admin interfaces
* Inquiries and search functions
* Data entry (CRUD) forms
* Business workflows
* Transactional interfaces/APIs
* Operational command and monitoring interfaces/APIs
* Interfaces with other applications/systems
* ... [your types]

You also need to identify the valuable data (e.g. confidential, sensitive, regulated) in the application, by interviewing developers and users of the system, and again by reviewing the source code.

You can also build up a picture of the Attack Surface by scanning the application. For web apps you can use a tool like the [[OWASP_Zed_Attack_Proxy_Project]] or [http://arachni-scanner.com/ Arachni] or [http://code.google.com/p/skipfish/ Skipfish] or [http://w3af.sourceforge.net/ w3af] or one of the many commercial dynamic testing and vulnerability scanning tools or services to crawl your app and map the parts of the application that are accessible over the web. Some web application firewalls (WAFs) may also be able to export a model of the appliaction's entry points.

Validate and fill in your understanding of the Attack Surface by walking through some of the main use cases in the system: signing up and creating a user profile, logging in, searching for an item, placing an order, changing an order, and so on. Follow the flow of control and data through the system, see how information is validated and where it is stored, what resources are touched and what other systems are involved. There is a recursive relationship between Attack Surface Analysis and [[Application Threat Modeling]]: changes to the Attack Surface should trigger threat modeling, and threat modeling helps you to understand the Attack Surface of the application.

The Attack Surface model may be rough and incomplete to start, especially if you haven’t done any security work on the application before. Fill in the holes as you dig deeper in a security analysis, or as you work more with the application and realize that your understanding of the Attack Surface has improved.

= Measuring and Assessing the Attack Surface =

Once you have a map of the Attack Surface, identify the high risk areas. Focus on remote entry points – interfaces with outside systems and to the Internet – and especially where the system allows anonymous, public access.
* Network-facing, especially internet-facing code
* Web forms
* Files from outside of the network
* Backwards compatible interfaces with other systems – old protocols, sometimes old code and libraries, hard to maintain and test multiple versions
* Custom APIs – protocols etc – likely to have mistakes in design and implementation
* Security code: anything to do with cryptography, authentication, authorization (access control) and session management

These are often where you are most exposed to attack. Then understand what compensating controls you have in place, operational controls like network firewalls and application firewalls, and intrusion detection or prevention systems to help protect your application.

Michael Howard at Microsoft and other researchers have developed a method for measuring the Attack Surface of an application, and to track changes to the Attack Surface over time, called the [http://www.cs.cmu.edu/~wing/publications/Howard-Wing03.pdf Relative Attack Surface Quotient (RSQ)]. Using this method you calculate an overall attack surface score for the system, and measure this score as changes are made to the system and to how it is deployed. Researchers at Carnegie Mellon built on this work to develop a formal way to calculate an [http://www.cs.cmu.edu/~pratyus/tse10.pdf Attack Surface Metric] for large systems like SAP. They calculate the Attack Surface as the sum of all entry and exit points, channels (the different ways that clients or external systems connect to the system, including TCP/UDP ports, RPC end points, named pipes...) and untrusted data elements. Then they apply a damage potential/effort ratio to these Attack Surface elements to identify high-risk areas.

Note that deploying multiple versions of an application, or leaving old, backup and unused code increases the Attack Surface. Source code control and robust change management/configurations practices should be used to ensure the actual deployed Attack Surface matches the theoretical one as closely as possible.

= Managing the Attack Surface =

Once you have a baseline understanding of the Attack Surface, you can use it to incrementally identify and manage risks going forward as you make changes to the application. Ask yourself:
* What has changed?
* What are you doing different? (technology, new approach, ….)
* What holes could you have opened?

The first web page that you create opens up the system’s Attack Surface significantly and introduces all kinds of new risks. If you add another field to that page, or another web page like it, while technically you have made the Attack Surface bigger, you haven’t increased the risk profile of the application in a meaningful way. Each of these incremental changes is more of the same, unless you follow a new design or use a new framework.

If you add another web page that follows the same design and using the same technology as existing web pages, it's easy to understand how much security testing and review it needs. If you add a new web services API or file that can be uploaded from the Internet, each of these changes have a different risk profile again - see if if the change fits in an existing bucket, see if the existing controls and protections apply. If you're adding something that doesn't fall into an existing bucket, this means that you have to go through a more thorough risk assessment to understand what kind of security holes you may open and what protections you need to put in place.

Changes to session management, authentication and password management directly affect the Attack Surface and need to be reviewed. So do changes to authorization and access control logic, especially adding or changing role definitions, adding admin users or admin functions with high privileges. Similarly for changes to the code that handles encryption and secrets. Fundamental changes to how data validation is done. And major architectural changes to layering and trust relationships, or fundamental changes in technical architecture – swapping out your web server or database platform, or changing the run-time operating system.

As you add new user types or roles or privilege levels, you do the same kind of analysis and risk assessment. Overlay the type of access across the data and functions and look for problems and inconsistencies. It's important to understand the access model for the application, whether it is positive (access is deny by default) or negative (access is allow by default). In a positive access model, any mistakes in defining what data or functions are permitted to a new user type or role are easy to see. In a negative access model,you have to be much more careful to ensure that a user does not get access to data/functions that they should not be permitted to.

This kind of threat or risk assessment can be done periodically, or as a part of design work in serial / phased / spiral / waterfall development projects, or continuously and incrementally in Agile / iterative development.

Normally, an application's Attack Surface will increase over time as you add more interfaces and user types and integrate with other systems. You also want to look for ways to reduce the size of the Attack Surface when you can by simplifying the model (reducing the number of user levels for example or not storing confidential data that you don't absolutely have to), turning off features and interfaces that aren't being used, by introducing operational controls such as a Web Application Firewall (WAF) and real-time application-specific attack detection.

= Related Articles =

OWASP CLASP Identifying the Attack Surface: [[Identify attack surface]]
 
OWASP Principles Minimize Attack Surface area: [[Minimize attack surface area]]
 
Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, Michael Howard http://msdn.microsoft.com/en-us/magazine/cc163882.aspx

= Authors and Primary Editors =

Jim Bird - jimbird[at]shaw.ca
 
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Talk:HTTP Strict Transport Security

2013-04-16T08:36:32Z

Shane Argo:

I would like to make a change to this page, but would like to check it's okay first. The IIS solution currently proposed on this page technically doesn't follow the spec, as [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14#section-7.2 Section 7.2] specifies that the header must not be send over non-secure connections. I have written [http://hstsiis.codeplex.com/ an open source IIS module] which implements HSTS as per the specification which I would like to reference it here, but I am concerned that it may be interpreted as advertising or some other unacceptable update. I have read the [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Keep_in_mind%29 Wikipedia editing guidelines] referenced from the [https://www.owasp.org/index.php/Help:Editing Help:Editing] page and this change appears to be acceptable. --[[User:Shane Argo|Shane Argo]] 02:21, 3 April 2013 (UTC)

Update re: open source HSTS IIS module after receiving approval from Michael Coates via email. --[[User:Shane Argo|Shane Argo]] 08:36, 16 April 2013 (UTC)

HTTP Strict Transport Security

2013-04-16T08:35:26Z

Shane Argo: Change made re: implementation in IIS after seeking approval from the original page author Michael Coates.

== Description ==

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.

 

== Examples ==

Example of the HTTP strict transport security header

Strict-Transport-Security: max-age=60000

If all subdomains are HTTPS to then the following header is applicable:

Strict-Transport-Security: max-age=60000; includeSubDomains

== Browser Support ==

{| width="400" cellspacing="1" cellpadding="1" border="1"
|-
| '''Browser''' 
| '''Support Introduced''' 
|-
| Internet Explorer 
| no support as of IE 10 (tested on 2013-01-01) 
|-
| Firefox 
| 4 
|-
| Opera 
| 12 
|-
| Safari 
| ?? 
|-
| Chrome 
| 4.0.211.0 
|}

 

== Server Side ==

The web server side needs to inject the HSTS header.

For HTTP sites on the same domain it is [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec#section-6.1 not recommended] to add a HSTS header but to do a permanent redirect (301 status code) to the HTTPS site.

An Apache HTTPd example that will permanently redirect a URL to the identical URL with a HTTPS scheme, is as follows:

<VirtualHost *:80>
ServerAlias *
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>

On the HTTPS site configuration the following is needed to add the header as [http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec#section-6.1 recommended by the standard]:
Header set Strict-Transport-Security "max-age=16070400; includeSubDomains"

The following links show how to do set response headers in other web servers:
* [http://wiki.nginx.org/HttpHeadersModule NGINX]
* [http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModSetEnv#Options Lighttpd]
* [http://httpd.apache.org/docs/2.2/mod/mod_headers.html HTTPd]

==== IIS ====
Whilst [http://technet.microsoft.com/en-us/library/cc753133(WS.10).aspx custom headers] can be configured in IIS without any extensions, it is not possible to restrict these headers to secure transport channels [http://tools.ietf.org/html/rfc6797#section-7.2 as per the HSTS specification]. HSTS has been implemented as per the specification as an [http://hstsiis.codeplex.com/ open source IIS module].

== Threats ==

HSTS addresses the following threats:
* User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker
** HSTS automatically upgrades HTTP requests to HTTPS for the target domain
* Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP
** HSTS automatically upgrades HTTP requests to HTTPS for the target domain
* A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate
** HSTS does not allow a user to override the invalid certificate message

== Links ==

[http://dev.chromium.org/sts Chromium Projects/HSTS]

[http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec HSTS Spec]

[http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Wikipedia]

[https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security Mozilla Developer Network]

[https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP TLS Protection Cheat Sheet]

[https://developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security Firefox STS Support]

[http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html Google Chrome STS Support]

[[Category:Control|Control]]

Talk:HTTP Strict Transport Security

2013-04-03T02:21:08Z

Shane Argo: Created page with "I would like to make a change to this page, but would like to check it's okay first. The IIS solution currently proposed on this page technically doesn't follow the spec, as ..."