I have trac set up together with subversion. I want to allow some people to be able to add tickets, but I don't want them to access the repository. There will be other users who will be able to access the repo via trac. Currently I am using Apache 2 for authentication.
How secure is trac? How difficult is it for someone with limited access to access the source via trac?
I am not asking on how to disallow access to the source via trac. I know how to do that.
The question again is: How hard is it for someone without access to the source to hack in and get at the source?
If Trac itself has access to your repository, and it gets compromised, the attacker has access to your repository by definition. In order to protect your repository from attackers taking over your Trac installation, you need to block Trac itself from accessing your repository; this will however also prevent it from giving access to the repository to anybody as well.
A compromised system still has all access permissions that it had before it was compromised, and whoever compromised it can make it do whatever they wish with its access permissions.
Funny thing, you actually can't rely on any answer provided here. I would say the correct approach is to conclude Trac is not that secure (just an assumption) and try to mitigate potential risks.
I assume your goal is to make sure "users" and "developers" can collaborate, but users will not be able to access sources under any circumstances (which is very good, by the way).
There are quite a lot of relevant recipes on the net, but I will provide the simplest one:
put your Trac behind Apache (you did that already)
use mod-rewrite to make sure "users" will not get access to [your URL]/browser, ...
configure Trac permissions as well
[paranoid mode], change default URLs in order to eliminate guessing
Basically, the idea is to filter users as early as possible in order not to rely on Trac's internal security.
You can also use OWASP Zed Attack Proxy Project to test Trac yourself:
The Zed Attack Proxy (ZAP) is an easy to use integrated penetration
testing tool for finding vulnerabilities in web applications.
It is designed to be used by people with a wide range of security experience
and as such is ideal for developers and functional testers who are new
to penetration testing. ZAP provides automated scanners as well as a
set of tools that allow you to find security vulnerabilities manually.
You can set permissions for every Trac user. For example, you can have user accounts that can only access the ticket system, but not the source browser, timeline or wiki.
In particular, you want to not grant the following permissions:
BROWSER_VIEW # View directory listings in the repository browser
LOG_VIEW # View revision logs of files and directories in the repository browser
FILE_VIEW # View files in the repository browser
CHANGESET_VIEW #View repository check-ins
I am not sure what you mean by "secure". Trac will enforce the permissions you have set for all its web access. It will not show the source browser pages to someone who does not have the proper permissions. In addition to that, you will have to configure SVN as well to not allow anonymous repository read access (otherwise they could by-pass Trac and access the repository directly).
This is possible.
trac-admin /path/to/project permission remove <user> BROWSER_VIEW
trac-admin /path/to/project permission remove <user> LOG_VIEW
trac-admin /path/to/project permission remove <user> FILE_VIEW
trac-admin /path/to/project permission remove <user> CHANGE_VIEW
This will remove all repository related permissions. We use trac, works well, haven't had any security problems as of yet.
Your question is hard to answer by nature. If you want to know about known security holes, you should check their own, or your distribution's, bug tracker. Debian doesn't report any security related bugs in trac, for example. So to the best of my knowledge, it is impossible to crack trac itself and gain ungranted access.
Of course, that doesn't mean there are no security holes. It only means they haven't been found by good guys (who would have reported them). But it's the best you can get when it comes to security, short of doing (or hiring people to do) a full source audit.
Related
I load sensitive details (eg, AWS Secret) into my node project with dotenv & an .env file, which I include in my .gitignore, as I've read that's best practice.
If I want to add others to the project, or even clone the repo on another system, what's the most efficient/safe way to transmit these sensitive details? I assume email/google drive are out, but I'm not sure what's 'in.'
My repo is private--does that mean the 'don't check-in API keys' advice is less concrete? As I see it, anyone with permission to see the repo will likely need relevant API keys, so it doesn't seem too unreasonable to simply check them in.
Security is always a trade-off with convenience. There are no real absolutes. Are you cool with anyone who accesses the repository and the (potential) git host having access to the keys? Are all developers' computer secure and use disk encryption? What do the keys give access to? Everything on AWS? Do you trust people with access to the repo enough to stay secure and not accidentally share things further? The point is that you need to try to fully understand in which ways the secrets may be leaked.
Personally I rather keep them outside of git and distribute keys to developers via usb sticks or encrypted email. And only to the people who need them. Only a subset of our developers actually need access.
Just make sure that you replace all your secrets if you do decide it's too risky. Don't just delete them from the repository. Once they are in there, they are in there forever.
How difficult/easy is it to break into Joomla backend & to access the pages which are only set to be accessible by selected Joomla users of the website? Is it safe enough to rely on Joomla's management system?
Yes, Joomla is quite secure system by itself. Although you have to be careful with third party extensions and always track update news for all components (including core) you have installed and use your judgement about updating them. Usually security issues spotted quite quickly and you have time before succeed attack.
Another thing keep in mind is proactive defense with all possible means you have in hands, this includes .htaccess and .htpasswd, also good idea to restrict ftp access to only local ips and use sftp instead.
Also check out the security extensions around JED, the ones which prevents high level DDoS and extend admin page access protection might be also helpful, usually they are simple modules or plugins.
And yes, do not forget change default username for superuser. And change all passwords ftp/superusers/mysql/htpasswd on regular basis.
Follow this simple rules and you will be fine, at least most of the time you will be fine.
While Joomla security is fairly good, you need to keep up with the patches and, as dmi3y mentioned, you need to watch the third party extensions.
When it comes to information security, nothing is ever perfect. This solution may or may not be appropriate depending on the type of information that you are looking to secure, the number of users accessing it and how you manage the user rights.
I have recently been tasked with finding a suitable installShield replacement and I am leaning towards InstallBuilder over Install4J and InstallAnywhere. Has anyone come across any issues with creating installers that installBuilder has been unable to handle? For example very strict security on the client machine.
*Comment added for additional clarity
For instance a system that has all accounts disabled sans the admin account with a very unique domain policy for instance, the inability to write files to the temp directory. Also how extensible is your product, from playing around with it I notice it is purely xml so is there anyway to write some extensions to the core?
this is Daniel from BitRock. Our installers do not need admin privileges in any platform (unless you explicitly require them) and can install as regular users. If you need to check permissions in the filesystem, registry, etc. from within the installer to see what is available, there is code to do that as well. I am not sure if the above answered your question. Can you provide more details about what you mean with restricted security in the client side? We take great pride in our level of support, and we encourage you to contact our support team with any questions or suggestions you may have, just to see by yourself.
You should also take a look at InstallJammer just for comparison. It's a lot more open than most of the ones you mention and gives you the ability do practically anything from within your installer.
I am developing a web application and I am wondering if someone has a full read-only access to my filesystem, can this person (assuming that he is aware of everything necessary) have a write access to the system?
For example, if you have a PHP script that outputs contents of any files on the server - will someone really be able to gain a write access to the system somehow? Like... can he rewrite the PHP script?
I'm talking about web servers... so both Windows & Linux related comments are welcome. Also, are there cases where the cracker could have a write access to most files, but not to all on the system?
I'm just curious. To sum up: "Can a PHP local file include vulnerability ever give the cracker a write access to the files?"
A malicious user could download your password file and get cracking, or perhaps read the MySQL user table and get the password for your MySQL root user. Then use that user to gain further access using a privilege escalation exploit or something similar.
Substitute password file for registry (or SAM) and MySQL for MSSQL and the same argument works on Windows. No, it won't be very easy but yes, they will succeed.
Do not give anyone full (read) access to your system, ever!
Let me rephrase. If I have a PHP application running and someone can read my PHP files through an insecure PHP script and has a read-only DB access, will he be able to crack my whole server?
Perhaps. The probability of someone being able to hack your server in that situation is non-zero, therefore you cannot afford allow such a security hole to exist. They may not be able to rewrite your PHP script, but a read-only db user can perfectly use an exploit in the database server for example.
Any accounts which have write access to a given directory have the potential of being exploited.
Security is all relative. Attackers don't follow rules and they won't necessarily pick the attack vector you've hardened against. If you're concerned, make it so that only a select group of users can write to a directory. Do not include service/daemon accounts in this group. Use limited accounts for daily use. Follow good password policies (length, complexity, change frequency, etc.). Limit your attack surface by closing unused ports, etc.
You may even go so far as to encrypt the file-system. This introduces complexity and there's a chance you'll get it wrong . If you're really concerned, you can take a pessimistic security stance and deny everyone any access except the bare minimum they need to do the job you've assigned them.
In the end, even if you're the only one with 'technical' access to a resource, you could still be tricked or blackmailed or otherwise coerced into granting access. The best you can do is make attacks difficult--not impossible.
I would like to have your opinion about the subject "version control",
but focusing on security.
Some common features:
allowing to access to source code using clients only
(no way to access the source code on the server directly)
granting permission to access only the
source code which I am allowed to modify (i.e.: a developer should be able
to access the source code related to his project only).
So it should be possible to create user groups and granting different
levels of access.
tracking modifications, check-ins, and check-outs and the
developers who made them...
...and, surely, I am forgetting something.
Which are the most "paranoid" version control systems that you know?
Which features do they implement?
My aim is creating an enviroment for developing applications managing sensible data: credit cards, passwords, and so on...
A malicious developer may insert backdoor or intentionally alter some security features. So the access to the source code should be controlled strictly.
I must confess that my knowledge of version control systems is poor, so, I fear, customizing SVN could be a hard task for me.
Thanks
Perforce is widely used in the Finance Industry where security of code is sometimes an issue.
You can setup gatekeepers and access controls to restrict visibility of code and produce audit trails for various activities for SOX compliance.
I know that the ones you want are not the ones you want. For example, Clearcase or Serena Dimensions can do all the above... but you'd be bonkers to want to use them. (ah, I hear you say, I'm the admin so I don;t have to take that pain. Well, these also require lots of care and attention - we had 8 Clearcase admins at the last company I worked for. You don't want the nightmare of continually helping users with them).
So. You can have the horrible ones, or you could just use the friendly, easy-to-use SVN and implement your own checkout-tracking (using http transport and Apache logs), and slap access control permissions on every directory. You'd also have to secure the end-repository on disc, but you have to do this with every SCM, even something like Dimensions stores its database in Oracle - if you had access to Oracle instance, you could fiddle with the saved bits, so you have to secure that anyway.
Perforce has those features and is a really good product imho.
Use a well-known, industry standard system like subversion. It can control access to individual projects very simply, and using the web server authz configuration can control individual access to specific files in each project.
The only non-stanard issue is logging check-outs. But the web server can easily log this information for you.
Your users will thank you.
github is a wrapper for git which provides these features for git server. Compared to raw git servers, it notably includes access control, and it also has useful web interfaces to the code for authorised users.