Security Issue

Issue #180 closed
Meni Nuriel created an issue

I have checked my Zurmo app with a penetration program, some erros and issues showed up, is it possible to fix them in the next relese?

Issue:

AUTOCOMPLETE attribute is not disabled in HTML FORM/INPUT element containing password type input. Passwords may be stored in browsers and retrieved.

Fix:

Turn off AUTOCOMPLETE attribute in form or individual input elements containing password by using AUTOCOMPLETE='OFF'


Issue: (Came up with many pages)

A cookie has been set without the HttpOnly flag, which means that the cookie can be accessed by JavaScript. If a malicious script can be run on this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible.

Fix:

Ensure that the HttpOnly flag is set for all cookies.


Issue: (Came up with many pages)

A cookie has been set without the secure flag, which means that the cookie can be accessed via unencrypted connections.

Fix:

Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel. Ensure that the secure flag is set for cookies containing such sensitive information.


SQL injection may be possible

The page results were successfully manipulated using the boolean conditions [tavcrm.co.il' AND '1'='1' -- ] and [tavcrm.co.il' AND '1'='2' -- ] The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was returned for the original parameter. The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

Fix

Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side. If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?' If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries. If database Stored Procedures can be used, use them. Do not concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality! Do not create dynamic SQL queries using simple string concatenation. Escape all data received from the client. Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input. Apply the privilege of least privilege by using the least privileged database user possible. In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact. Grant the minimum database access that is necessary for the application.


Parent Directory

It is possible to view the directory listing. Directory listing may reveal hidden scripts, include files , backup source files etc which be accessed to read sensitive information.

Fix

Disable directory browsing. If this is required, make sure the listed files does not induce risks.


Issue

Secure page can be cached in browser allowing the browser and proxies to cache content

Fix

The best way is to set HTTP header with: 'Pragma: No-cache' and 'Cache-control: No-cache'. Alternatively, this can be set in the HTML header by: <META HTTP-EQUIV='Pragma' CONTENT='no-cache'> <META HTTP-EQUIV='Cache-Control' CONTENT='no-cache'> but some browsers may have problem using this method.


Issue

The cache-control and pragma HTTPHeader have not been set properly allowing the browser and proxies to cache content

Fix

Whenever possible ensure the cache-control HTTPHeader is set with no-cache, no-store, must-revalidate, private, and the pragma HTTPHeader is set with no-cache.


Issue

A private IP such as 10.x.x.x, 172.x.x.x, 192.168.x.x has been found in the HTTP response body. This information might be helpful for further attacks ta

Fix

Remove the private IP address from the HTTP response body. For comments, use JSP/ASP comment instead of HTML/JavaScript comment which can be seen by client browsers.


Comments (7)

  1. C F

    @Meni Nuriel You know, you really have to understand what a security tool is trying to tell you before you can take any meaningful action.

    1. Autocomplete: This issue is fundamentally a feature of the user's agent/preference. Regardless of merit it is inappropriate to address this in the webapp.
    2. HttpOnly: This is an architecture issue that can far too limiting in apps that are JavaScript heavy. Zurmo may not quite be there yet, but its headed in that direction. There are other far more effective ways that don't enforce architecture changes, such vigilance toward XSS attacks. Moreover that's not the only source of possible session leakage.
    3. 'Secure" flag: This... is... a peculiar observation.. and is more so a reflection of how your server is setup. Anyone concerned with data over the the wire should be using SSL anyway which renders this moot. If someone installs Zurrmo on a server without SSL, using this 'flag' would render the application inoperable.
    4. SQL Injection: Now this... could be a serious concern, but it could also be a red herring. Its important to note the URLs and parameters this behavior was reported for.
    5. Directory Listing: Again, this is a this is a reflection of how your server was setup. Perhaps you should have audited your server before installing Zurmo. @Jason Green It's not an outrageous suggestion to ship Zurmo with an .htaccess and a web.config that turn directory browsing off.
    6. "Secure" Page caching: But what's a secure page? What has data on it that's not cachable? Customer info? Client account data? That may well account for 70% of the app's traffic and it is quite reasonable to cache, especially internally and client side. It is a poor control to rely on a no-cache header as ISP caches can and do ignore this. Again, concerns with over the wire exposure must be directly addressed with SSL.
    7. I strongly suspect this is because you ran this tool against your own IP. Please, tell me I'm mistaken.

    What tool gave this report? It may have more geared toward your own internally developed apps, and gave recommendations unique to you.

    It does bear repeating, please post the URLs and parameters posted in re the SQL injection, or, better still, email a project maintainer directly.

  2. Jason Green

    thanks guys. feamsr00 after you get feedback from meni, you can make recommendations as to a final list of changes we should make.

    thanks, Jason

  3. Meni Nuriel reporter

    feamsr00 you are absolutly right, it was used against my own instalation and set up. I'm not an expert on the subject of security and if the issues mentioned looked at and are not of any risk, so its very good.

    thanks, meni

  4. Log in to comment