Application design using HTTP and HTTPS together

I need to build a large web-application some开发者_开发百科 part of which contains sensetive data and should be secured. I cann't use https entirely due to performance so my suggestion: use http for the unsecure part and https for the secure part. But it seems to be a poor application design to mix http with https from a perspective of maintainability and security. What is the best practices for such a case(some helpful links to articles or books would be very appreciated)?

However, if mixing http/https is acceptable then how can I prevent the next vulnerability: During a http session a man-in-the-middle changes some piece of html that surreptitiously makes a malicious request directly to https page => the https part of the application actually becomes unsecure due to the html part?

---

Enabling SSL (HTTPS) does not mean your application will be secure.

First, design your application to enable secure scenarios. It seems you don't know much about designing secure apps. In short, very basically, you need to accomplish these two things:

• authentication of the user before providing access to any secured resource (page),
• authorization of each request to a secured resource.

Note that, typically, for public-facing web apps server-to-client authentication is covered by SSL (HTTPS; providing the server's certificate which the browser can validate) and client-to-server authentication is covered by some sort of username/password combination, OpenID, etc.

Then, start thinking about how to establish encryption (SSL, very roughly speaking). For low-volume sites SSL implementation if your web server of choice is fine. Fow high-volume sites many hardware-accelerated solutions exist on the market.

---

There is no point in using HTTPS for only passwords. If at any point you transmit a session id that is authenticated or will become authenticated over HTTP then you are in clear violation of OWASP A9-Insufficient Transport Layer Protection. Attack tools like Firesheep can then be used to hijack accounts.

HTTPS is a very light weight protocol, the most expensive part of the protocol is the handshake which is cached for future transactions with that client. To have a mixed HTTPS/HTTP application in a secure manner you will have to have a 2nd domain name. So have your main domain www.domain.com as your authenticated one. Then have a static.domain.com for insecure content. Keep in mind that if you are displaying mixed https/http content on the same page then an attacker can influence the application similar to XSS. HTTP-Only Cookies can be used to prevent the session id from being hijacked. But this is not an ideal solution. If you really care about security you'll use pure HTTPS.

---

If using ASP.NET checkout this question: ASP.NET Security Best Practices. It covers security aspects which are relevant outside of ASP.NET such as XSS which is related to the issue regarding HTML tampering.

Overall, if non-secure pages are not expected to receive a lot of traffic then it is simpler to require HTTPS throughout the web application. This way you can have a simple rule which prevents non-HTTPS pages from being opened.

If however you determine performance to be a true concern, it is possible to have a web application utilizing both protocols. Then however you must evaluate all possible security holes. For example, if cookies are used for authentication on secure pages, those cookies must only be sent via HTTPS.