Hacking the Code ASP.NET Web Application Security [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Hacking the Code ASP.NET Web Application Security [Electronic resources] - نسخه متنی

James C. Foster, Mark M. Burnett

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید






Protecting Communications with SSL











Summary:


SSL provides easy-to-use encryption for HTTP communications


Threats:


Information leakage, data corruption, man-in-the-middle attacks, brute-force attacks


SSL is a protocol that involves many of the cryptographic techniques described in this chapter, yet it is simple enough to use that most users are completely unaware of the underlying technologies and know it only as the small lock icon in their browser. SSL provides basic encryption and authentication for all HTTP traffic.

A client and server establish an SSL session by the client requesting a certificate from the server. The server responds by sending its certificate and its cipher preferences. The client then generates a master key, which it encrypts with the server’s public key, and transmits that key to the server. The server authenticates itself to the client by returning a message authenticated with the master key. All data is now encrypted and authenticated with keys derived from this master key. The process can optionally include a similar method for authenticating the client. SSL is a crucial piece of any Web application’s security process. It does not protect against all types of attacks, but it provides the basis for many of the other techniques described in this book.





Warning

Despite best efforts by some companies to market SSL as the solution for server security, it is important to note that SSL does nothing to make the server itself secure. SSL authenticates the server to the client and ensures the privacy of the communications between the server and client. It is the digital equivalent of a security envelope.


Because the encryption process requires more CPU cycles, SSL does put an extra load on the server, especially on slower processors. For this reason, many Web site operators choose not to use SSL, even for sensitive traffic. It is difficult to justify sacrificing the security benefits of SSL, however, so you might want to consider some of these techniques to improve performance:



Upgrading hardware or load balancing across multiple servers



Using hardware SSL accelerators



Optimizing Web content for minimal traffic



Even inexpensive hardware upgrades or SSL accelerators can make up for the extra load required for the SSL traffic. Note that most of the additional processing comes from the initial handshake that involves the much slower asymmetric cryptography used to exchange the session key. Once the key is established, the rest of the traffic is encrypted with symmetric cryptography using that key. Since most symmetric algorithms are quite efficient, there is a much smaller overhead once the session is established.





Tip

Some Web sites, in an effort to avoid the overhead of SSL, use it only for the initial authentication process and then switch back to a normal HTTP connection. However, most of the processing overhead is for the initial session handshake that involves asymmetric cryptography. So, if you go through the process of initiating an SSL session, you might as well keep the SSL connection for the rest of the traffic.


SSL is always important, but in some scenarios you should always use SSL:



When transferring sensitive information



When using forms authentication



When using basic authentication



One mistake that many programmers make is not keeping an SSL session once a user authenticates using basic authentication. With basic authentication, the browser automatically sends user credentials with every request. Not only should you keep the SSL connection, but you should be careful that all page elements, such as images, style sheets, and scripts, are also sent over the SSL connection. One way to avoid this mistake is to use a unique host name for your SSL traffic, such as secure.example.com.

SSL is based on a well-established public certificate infrastructure, but technology cannot make up for human shortcomings. A user’s browser may show a lock icon, but few users will actually open the site’s certificate to make sure it is valid. Even if they do, it might be possible to produce fake information that looks authentic. Even if the browser warns the user of an invalid certificate, many users are trusting enough to continue browsing the site anyway. The only way to prevent this type of attack is to provide detailed information on your certificate and educate users about SSL and SSL certificates.

Security Policies




Always use SSL for protecting sensitive HTTP traffic.



Upgrade hardware or use an SSL accelerator to handle the processing overhead of SSL.



Once the session is established, keep using SSL as much as possible.



Be careful to use SSL for all included page elements.



Educate users about SSL and SSL certificates.



/ 96