لطفا منتظر باشید ...
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to and click on the form. You will alsogain access to thousands ofotherFAQs at ITFAQnet.com.
1. | Does SSL add enough security to make it worth the extra load? |  |
2. | Can I create a different machineKey setting in each application’s web.config file instead of a single setting in the machine.config? | |
3. | Is it more secure to manage and store session state on the client or on the server? | |
4. | Why is it so important to use a strong random-number generator for the session token? | |
5. | I run a Web-based e-mail Web service, and for business reasons I must place the session token on the URL. How can I prevent the client’s browser from sending the URL token in the Referer field when a user clicks an external hyperlink? | |
Answers
1. | SSL does not solve all problems, but it does protect the user from many types of attacks, and you should therefore use it whenever possible. On a slow server, SSL can sometimes double the processor load, but it has a less significant impact with a more powerful CPU. Furthermore, you can offload SSL handling with specialized hardware. If your site deals with sensitive user financial, personal, or communications data, utilizing SSL should be mandatory. |
2. | Yes, this is actually the preferred method for securing a server with multiple users, such as with a Web hosting service. To configure this, use the IsolateApps setting as follows: <machineKey validationKey="AutoGenerate,IsolateApps" |
3. | It is best to store and manage session state information on both the client and the server. If you rely only on the server, it is easier for an attacker to take over a client’s session without knowing about the client. If you do it only on the client, it is more difficult to protect from session fixation, and there is no way to revoke a user’s session after a security incident. |
4. | The main reason for a strong random-number generator is to prevent guessing or brute-force attacks of the session token. For example, an attacker could create a script to submit thousands of session IDs until it finds a valid session. The stronger the random number, the more difficult it is to find a valid session. To be effective, the random numbers must be large, unpredictable, and evenly spread across the entire keyspace. If you have a 120-bit random number and 10,000 active sessions, you should feel safe knowing that for every active session, 132,922,799,578,491,000,000,000,000,000,000 session IDs are not valid. Even using an automated script, it would very difficult to come across a valid session ID. |
5. | If you place the session ID on the URL and the user clicks a link, the destination Web site will be able to see the original URL, including the session token, by looking at the HTTP Referer field. Sometimes an attacker can use this flaw to take over a user’s session. The easiest way to prevent this attack is to wrap all URLs with a URL of your own, passing the original URL as a parameter. So, for example, you could end up with something like this: http://www.example.com/externallink.aspx?original=www. Next, have externallink.aspx grab the original URL parameter and forward the client to that site with a client-side redirect. The external site will only see the link coming from externallink.aspx. |
