ADSelfService Security

Question

Hello,
These questions relate to 2014.1.
Our ADSelfService site has been configured to allow only password changes.
We would like to expose the ADSelfService website on the internet. Our security team has identified a couple issues we would like to mitigate if possible.
Can you recommend any changes we can make to mitigate these issues?:

1) Threat - toc.html is an example, most of the Help pages are flagged with this threat
URL: https://\*\*\*\*\*\*\*\*\*/Help/toc.html
The page can be easily framed. Anti-framing measures are not used.
Impact
Clickjacking and Cross-Site Request Forgery (CSRF) can be performed by framing the target site. An attack can trick the user into clicking on the link by framing the original page and showing a layer on top of it with dummy buttons.
Solution
Two of the most popular prevention are: X-Frame-Options: This header works with modern browsers and can be used to prevent framing of the page. Note that is must be an HTTP header, the setting is ignored if it is created as an "http-equiv" meta element within the page. Framekiller: JavaScript code that prevents the malicious user from framing the page.

2) Threat
URL: https://\*\*\*\*\*\*\*\*\*\*\*/SignIn.aspx?ReturnUrl=/default.aspx
URL: https://\*\*\*\*\*\*\*\*\*\*\*/SignIn.aspx?ReturnUrl=/default.aspx&AspxAutoDetectCookieSupport=1
The cookie does not contain the "secure" attribute.
Cookies with the "secure" attribute are only permitted to be sent via HTTPS. Session cookies sent via HTTP expose an unsuspecting user to sniffing attacks that could lead to user impersonation or compromise of the application account.
Solution
If the associated risk of a compromised account is high, apply the "secure" attribute to cookies and force all sensitive requests to be sent via HTTPS.

3) Threat
URL: https://\*\*\*\*\*\*\*\*\*\*\*\*/SignIn.aspx?ReturnUrl=/default.aspx
The cookie does not contain the "HTTPOnly" attribute.
Cookies without the "HTTPOnly" attribute are permitted to be accessed via JavaScript. Cross-site scripting attacks can steal cookies which could lead to user impersonation or compromise of the application account.
Solution
If the associated risk of a compromised account is high, apply the "HTTPOnly" attribute to cookies.

Answer 1

Hello,

1. This applies only to help pages. The thing is that help pages are stored as static HTML pages and served as static content. The pages that are not served as static content do not allow framing by default.

2. Session cookies cannot be marked with the Secure flag because cookies marked with the flag can be sent only over an encrypted channel (HTTPS). Currently, all security sensitive cookies are marked with the HttpOnly attribute. Starting from the next major version, Adaxes 2015.1, the authentication mechanism will be changed completely, and such cookies will not be used at all.

If you want, as an additional security precaution, you can enable SSL for Adaxes Web interfaces. This can be done the same as for any other IIS web application.

3. Currently all security sensitive cookies are marked with the HttpOnly attribute. The cookie that you are talking about is probably a cookie named AspxAutoDetectCookieSupport. This cookie is a part of .NET standard mechanism for detecting whether the client browser accepts cookies. We cannot mark this cookie as HttpOnly, however this is not necessary. The cookie does not contain any security sensitive information.

Comments

I found what appears to be the suggested mitigation. Is this what you suggest to mitigate item #1?

To configure IIS to send the X-Frame-Options header, add this your site's Web.config file:
<system.webServer>
...
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
...
</system.webServer>

---

Hello,

No, what we meant in the 1st item is that all content that can be compromised by framing it, i.e. dynamic content, is already protected and does not allow framing. The only pages that allow framing are help pages. These are just simple HTML pages served by the IIS server as static content, and do not pose a security risk of being framed. These pages are not even protected and available even to unauthenticated users.