9

I am developing a system to be used internally within a company, but possibly also externally at some point in the future. From the standpoint of the system's initial users - staff, the program is open source, as they have access to the repository where code is stored. They don't have access to server configuration, databases and such.

The system is web based and there are several classes of users, each with their limitations regarding what they can see and do. I'm not going to discuss the exact authentication and authorization mechanisms in use, as I think that would be beyond the scope of the question. Let's assume one is unable to trick the server into doing something he or she is not allowed to do or see (in terms of content, like articles).

However, there is currently just one set of HTML, JavaScript and CSS resources downloaded by all users, regardless of their access rights. I have decided not to have separate versions of all files in order to reduce necessary work.

With little fiddling with cookies you can enable the admin interface as it is included in site resources anyhow. You can see what it looks like and you can see what it could do. Meanwhile, you cannot actually do anything with it, as the server would know you are not a privileged user and decline to satisfy any requests you make, that you wouldn't normally be able to do.

I can't find any issue from usability standpoint as only "hackers" would run into a glitched admin interface and no regular users.

I am looking for negative implications from security standpoint.

My questions are:

  • What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?
  • Is having such functionality exposed a really bad practice I should immediately address?
  • If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

3 Answers 3

3

Must say a self explanatory question written by a man who knows exactly what he wants. You've got some fine responses already, contributing my penny as below.

  1. It is extremely common to have code base accessible to developers/testers(employees) however there should be precautions to be taken like if any encryption keys are present they'd not be part of normal code, no plain text passwords in code etc.
  2. It is best practice to let people have access to only that information which they need for performing duties nothing less nothing more else it may cause data leakage/breach of confidentiality/breach in the principle of least privileges etc.
  3. If an attacker could see client-side code they are not supposed/allowed to use, they will be able to create an attack plan based on the data available (ex form name, name and datatypes of fields, sequence in which they are queried, any default values, development comments etc. Trust me if I had all these details nothing can stop me from taking the site down with dedicated efforts)
  4. Yes if this is the case presently then it should be addressed immediately.
  5. If this is an open software then also there are scenarios to be considered like Is sensitive data present in code (username-passwords, encryption keys, external communication details, etc)? If yes then this must be handled in a repository which is not accessible to everyone. If you are giving a development environment to employees then make dummy values of these(data scrubbing) and then push it for people.
  6. This was all about code repository, come data/application and there will roles, groups and permissions for segregation of access that is mandatory both from DB and code perspective,failure to do so will lead to missing function level access control(you don't want to have that).

Ok I have written too much, to summarize if you keep the application the way it is you are keeping attackers (insider/outsider) optimistic for application being vulnerable to all of OWASP top 10 Risks.

Solutions (you never asked them but I don't want to keep the loop open)

  1. Seperate code repository for configurations, use dummy configs in development environment.
  2. Never keep anything open/readable in production environment for people who should not see it.
  3. Even if it seems open now once it's gonna be open for externals you'll need permissions and access control measures, implement them now and you'd not have to worry about modifying the architecture after a year or two when the code would have grown.
  4. Don't give leads/comments/code on production pages that's goldmine for attackers.
    1. Follow OWASP top 10 risk handling guidelines.

I can add more but I feel these would suffice the need for now.

2
  • Thank you for this really detailed answer! The repository uses default values for sensitive configuration like database connection settings, private keys, etc. These settings are all changed on production and are not currently listed anywhere except on production servers themselves. In the future, they may reside on some wiki page only accessible to support personnel. Regarding "if I had all these details nothing can stop me from taking the site down", what would you do as the attacker? I'm asking as if it remains open source, attackers would be in this position. Jun 26, 2016 at 6:16
  • Create exploits based on the values available for Injection, XSS, CSRF, Insecure Direct Object References, check probable security misconfiguration, unvalidated redirects and forwards and what not. As I said it all depends on what all data is available and how can use it to create exploits. And creating exploits will be easy if it is open source, it will be just about what fancy data you store in the database and how intriguing it is, What do you think? Jun 26, 2016 at 6:46
3

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

It may be easier to exploit vulnerabilities such as CSRF or missing access control if an attacker has access to the client-side code and thus to the requests that may be performed.

It may also be easier to find vulnerabilities such as XSS. Vulnerabilities such as XSS may now also target lower-privileged users as well as higher-privileged users, as both have access to the UI.

Is having such functionality exposed a really bad practice I should immediately address?

Not really. If it's not needed, I wouldn't expose it though, because of the reasons outlined above.

If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

If it's open source, it's not even security by obscurity, and hiding it isn't strictly necessary (although still not a bad idea, especially because of the possibility to exploit XSS vulnerabilities).

1

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

Even if the hacker is not allowed to / unable to use the code they see, they can still gain the benefit of additional information, which they use to later attack your site. A particularly valuable source of information is the JavaScript information contained on the client side. If a hacker see how:

  1. How your code is structured
  2. Input is handled
  3. Client side events are handled

he or she gains valuable information to exploit your website based on such information.

1
  • 2
    But might not there be code on non admin pages also? Jun 25, 2016 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.