nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How safe is Fisheye?

Aaron Jones4

We're in the process of getting up and running on a many of Atlassian's products, but Fisheye is causing a lot of concern. Most of the concern centers around the ability to download the raw source code and the fear is that some malicious person could script the traversing of a repository and download the entire thing.

Does Fisheye have any protection against this sort of attack? Can the Raw view and download raw files buttons be disabled (other than a CSS hack)? Or has this been completely overlooked?

Accepted answers

Tom Davies

You can set FishEye's permissions so that only a particular set of users can see a particular repository.

It sounds as though you want to have users who can see files in a repository without seeing 'too much' of it. Is that correct?

If particular parts of a repository are particularly sensitive you can map the same VCS repository to several FishEye repositories, each of which scans a different subset of the VCS repository, and each of which has a different set of permissions.

There is no way of preventing a user who has access to a repository downloading the source of all the files in the repository -- even if it was possible to remove access to raw source code they could simply download the difference between each revision and compose them.

All comments

JamieA

Why script a web crawler when you could just check out the repository?

I think the idea is you only give access to people who have access to the source repo... in this respect fisheye is very weak, because it doesn't have the capability to read the permissions of your source repo, be that subversion or perforce or whatever, therefore you need to define all your permissions twice.

Stash is a bit more integrated and "industrial".

Aaron Jones4

A web crawler is just one approach. You could use wget or curl in much the same way.

The hope was to allow more people access to Fisheye than we provide to the respository because of licensing restrictions (Perforce) and because it's more intuitive to use - especially for QAs. However, with that expanded availability comes greater risk.

If Fisheye has no protections for this, we could certainly be at an impass.

JamieA

I put wget/curl in the same basket as web crawlers. You could save yourself some money and just run p4web in guest mode.

But, my point stands, if you are concerned about people seeing code they should not, you should only give access to fisheye to those people that have read access to everything in p4, and also see https://jira.atlassian.com/browse/FE-226

Tom Davies

You can set FishEye's permissions so that only a particular set of users can see a particular repository.

It sounds as though you want to have users who can see files in a repository without seeing 'too much' of it. Is that correct?

Aaron Jones4

Lukasz Pater over at Atlassian was actually able to help me with this via a ticket I'd opened. To remove access to the raw source, we need to create a small plugin that would prevent access to a specified url, or log that access. To do that you'd need to create a servlet filter module.

public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        String url = ((HttpServletRequest)servletRequest).getRequestURL().toString();
        if (url.contains("/~raw")) {
            ((HttpServletResponse)servletResponse).sendError(403);
        } else {
            filterChain.doFilter(servletRequest, servletResponse);
        }
}

The code returns a 403 Forbidden error whenever someone attempts to access any of the raw source. While this isn't a complete answer, it certainly makes it more difficult to get at the raw source without additional effort and satisfies our needs. This combined with the other recommendations about limiting repo visibility should put us in an acceptable situation.