I've hosted a web application (using Shiny, a R package for interactive web applications) on AWS EC2. I've also set up an authentication mechanism on the app with shinymanger(https://datastorm-open.github.io/shinymanager/). This authentication requires reading and writing from a sqlite database (database.sqlite) that stores user information (username, password, etc). In order to create new users in the authentication system, I need "write" permission, so I changed the permissions of the sqlite database with chmod 777
Screenshot of user permission of sqlite database
Question: The AWS server is only owned by one other person, but I'm worried that since the web application is hosted on a public IP address, bad people could infiltrate the sensitive data. Is this permission setting safe? If not, how do I change the permission setting so that I can still read, write, and do everything that 777 allows, but safer!
I notice that everything is run by ubuntu.
If you're worried about security, you will probably want to run something like:
600 (rw-------) <- rule of least permissions. As long as the file is owned by the same user that the sqlite application runs as, this will work.
660 (rw-rw----) <- safe, group extended permissions. Allows members of the file group to r/w. Probably not needed, but can be used if multiple things will need r/w.
700 (rwx------) <- flexible user. Allows all actions from the user owning the file. Probably more permissions than needed, but I'm not super deep into SQLite (from my understanding it should only need r/w?)
770 (rwxrwx---) <- flexible group. Same as extended group permission, just also allows execute. Probably more permissions than are needed.
The one thing I would not recommend, specifically for a DB with file security concerns is any world permissions. The third perm should remain 0 to keep the file locked down to at least user/groups.
If you're curious about the full 'best practice'- I would recommend making an application specific user, changing the owner of the directory and file to that application user, and then applying all permissions as x00 permission sets (700 for directories, 600 or 640 for files).
Related
We have set up the Remote Config for our app at Google Firebase, which is accessed via a Service Account that is meant to have a Role with minimal requirements. Would be perfect to have permissions for read-only access to the Remote Config only.
However we cannot come up with the working set. Firebase Viewer role works fine, but there are 107 permissions attached to it. Obviously we don't need that many? For example I successfully removed all prefixed with automl. (20+ or something) But as soon as I go deeper for seemingly unrelated ones, like: firebasedynamiclinks.domains.list or logging.logEntries.list or cloudtestservice.environmentcatalog.get it blows up and remoteConfig endpoint for the project starts to return http error 500 (internal error). Which in my interpretation signals about some conflict in the remaining set of permissions.
Are there some determined permissions for reading Remote Config only?
Firebase IAM Permissions lists the roles required for each product.
The only Remote Config permissions are cloudconfig.configs.get and cloudconfig.configs.update
Since you'd like your service account to have read-only access, the only permissions you should need are cloudconfig.configs.get and the permissions required for all roles (i.e., firebaseanalytics.resources.googleAnalyticsReadAndAnalyze, resourcemanager.*, servicemanagement.* and serviceusage.*).
My team have been asked to 'enhance' a web app to permit the following. Is this considered a security risk in a web app? I'm not sure about this.
"Be able to access directories, for exporting and importing [data into the database] , outside of the virtual directory"
In other words the requester wishes to be able to navigate to a data file anywhere outside the application's IIS virtual directory, presumably when importing (or exporting) data.
I think this means on the web server, but it may mean local files on the client machine (to be clarified). But either way the question stands.
If you are talking about going outside the boundaries of the web application, that means a risk. Once you allow a particular user to go beyond your web application, then there is no more control in what that user could do with the webserver.
Have a look at path traversal attacks:
https://www.owasp.org/index.php/Path_Traversal
Also, here is a list of things to consider in order to avoid this:
https://www.owasp.org/index.php/File_System#Path_traversal
Any questions, just let me know.
Regards,
Fabio
#fcerullo
The question does not stand 'either way'. They are different questions. If it is about being able to select a file from the local computer to send to the remote server then that is pretty routine. e.g. one does it all the time while attaching a file to an email. The user is the one who initiates the file choice AND it is their file to send to the web app. No security hole here.
IF you have a need to allow clients to be able to browse the server computer for all sorts of files, then that itself is NOT a security hole. That is what you wanted, you got it. It is a security hole ONLY when you did not mean that the client should be able to grab hold of files off any whichever directory on the server. This whole scenario is classified as security issue because more often than not you do NOT want clients to have access to all inclusive files on the server. Typically the client needs to be able to access only certain files. Restricting you to virtual directory is one way of doing it. e.g. would you want your clients to be able to grab hold of the actual DB files with records of all users of your web site and then load that DB file in their own DB?
If you need to go beyond that, you need to implement mechanisms in place that allow access to only certain files. Remember your web server is running in the context of some user on the server OS. When the client request comes to the server, it that that web server user under which the command executes. So you cannot achieve security by simply putting in permissions for that web server user.
We are extending an existing software product, which uses Active Directory to store user credentials to a cloud solution to store user credentials.
I am wondering how we can migrate/port these AD passwords to new database instead of asking users to reset their passwords. I know we cannot retrieve the plain password but rather I would like to understand how we can port these passwords and use a specific decryption library to validate these passwords.
We can just move this passwords to new SQL database but how are we going to validate the password? Which encryption algorithm and salt we are going to use?
Thank you,
I’ve spent most of this month working with a customer who is consolidating various Active Directory forests into a single domain. We didn’t use any third party tools – just the standard Microsoft utilities, i.e. Active Directory Migration Tool (ADMT) v3 and Exchange Migration Wizard (one of the Exchange Server 2003 deployment tools) – but they seem to do the job.
As migrating several hundred users to new accounts (with new passwords) would cause a huge number of support calls, I wanted to get the ADMT password migration DLL working. This took some time, but with the help of my enterprise support colleagues (effectively a PSS call), we found a way through. This is what was required:
(For reference, both the source and target domains were in Windows Server 2003 domain and forest functional mode, running Windows Server 2003 with a mixture of service packs 1 and 2.)
Make sure that there is a trust in place between the source and target domains.
Install ADMT by running admtsetup.exe and follow the installation wizard on the computer that will be used for the migration (I used a domain controller in the source domain but ideally you would have dedicated computers for migration activities and it seems logical that this should be in the target domain).
If not already created by ADMT, create a new domain local group called domainname$$$. This group must be empty, and is required in order to migrate the sIDHistory information between source and target accounts.
On the domain controller that will be used to export the account information (usually the DC holding the PDC Emulator operations master role for the source domain), create/set a value of 1 for a DWORD registry key called TcpipClientSupport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\.
In both the source and target domains, ensure that success and failure auditing is enabled for account management.
On a computer with ADMT installed, create a password encryption key for each source domain, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:create /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
(the domainname can be specified in NetBIOS or DNS format.)
On the domain controller in the source domain that holds the PDC Emulator operations master role, connect to the computer with ADMT installed (e.g. via the c$ administration share) and access the %systemroot%\ADMT\PES folder.
Run pwdmig.exe to install the ADMT Password Migration DLL and follow the installation wizard. During the installation, supply the password encryption (.PES) file that was created earlier.
This is the step that’s not in the instructions – even though the password encyption file was supplied during the installation of the ADMT Password Migration DLL, it still needs to be imported manually on the PDC Emulator, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:import /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
On the domain controller that will be used to export the account information, create/set a value of 1 for a DWORD registry key called AllowPasswordExport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\. Note that this key constitutes a security risk and should only be enabled during the period of migration.
Restart the computer with the ADMT Password Migrator DLL installed.
Start the Password Export Server service.
Most of this is exactly as per the documentation – the main difference is the need to manually import the password encryption file. Without this, I was receiving the following message:
Error
Unable to establish a session with the password export server. The source password export server and the target server do not have the same encryption key for the source domain.
Finally, what permissions are required? I used Local System for the Password Export Server service. For everything else, I used an account which had been created in both forests with identical passwords and which was a member of the Domain Admins group. That’s a little excessive, and best practice would involve using an account with the minimum required permissions. Basically, an account is required that is:
Domain administrator in the source domain.
Local administrator on the computer on which ADMT is installed.
Delegated permissions on OUs that are targets for resource migration in the target domain, including the extended right to Migrate SID History (visible in the Security for an object using the Advanced Features view in Active Directory Users and Computers).
Further advice can be found in the ADMT v3 Migration Guide.
One option would be to implement a password filter for AD. This would allow you to capture the password as passwords get changed. I have used several products that implement a password filter to assist a ad migration, howevere I have not implemented it myself so the best I can do is suggest the Microsoft doc on it. This isn't a great option if users are not forced to change their password or cannot change this password.
https://learn.microsoft.com/en-us/windows/win32/secmgmt/password-filter-programming-considerations
Another option would be to setup a product in-between the product login and AD to capture and migrate password. Products do exist that implement a ldap interface for exactly this purpose. The product I have seen for this is Radiant logic but I believe there are other products.
https://www.radiantlogic.com/solutions/overview/how-radiantone-works/
I am quite confused about this and none of the texts / docs / SO questions have elucidated the matter for me.
I want my asp.net MVC app to be able to save an XML doc to a folder on the server. But I am getting an exception...
Access to the path 'D:\blah\blah\folder\xml_data.xml' is denied.
So as I understand it my application is running under a user account that does not have write permissions.
I think I had this problem before and my solution was to contact my web host and ask them to give my site permissions.
But what if I want to create my own custom set of roles with corressponding permissions? Do these have to be added into IIS? Would I have to create a list and then hand it over the the web host? What would such a list look like? As I understand it, it is not possible to configure roles and permissions in web.config, is that correct?
Once I have the roles and their permissions set up how to I set the default role for the app to run under and also how do I programitically change the role that the app is running under?
ps. I don't want to use asp.net membership I would like to know how to set this up myself.
Use asp.net membership. I don't care if you don't like it. Use it. It's easy, it's simple, and it gets security right. You will mess security up if you do it yourself and don't know what you're doing.
People give membership a bad rap, it's a good tool. Most people just make the wrong assumptions about it.
You define your roles in the membership/role API. This is stored in your database. You can't have roles without a user to apply them to, so you need a membership system of some type.
EDIT:
There are two kinds of users here. The first is the user that the ASP.NET worker process runs as under IIS. This is the user that your host must define, and allow to access various folders to access files.
The second is the IIdentity user of asp.net, this is the user that asp.net defines for the logged in web user, and this is completely seperate from the Worker process user. IIdentity users have no inherent operating system rights or privileges, other than those assigned to the worker process identity.
In other words, IIDentity based users run as the same Worker process identity in IIS.
The exception to this is when you define "impersonate=true" in the web.config, and this allows the worker process to "log on" to the OS as the user in question. In other words, the worker process will run as the web users credentials. This requires that the web user have credentials in the OS as well.
The other exception is that you can specify a specific OS user to impersonate in the web.config. But, again, there must be an operating system user to impersonate. Also, impersonation is a very expensive operation and takes a lot of system resources.
See http://msdn.microsoft.com/en-us/library/aa292118(v=vs.71).aspx
We currently use a connection string to authenticate our database credentials. Due to grown and compliance the developers are no longer allowed to "see" the database credentials that our websites use. Are solution to this problem is use Integrated Authentication. We planned on setting up a user per App Pool and then allowing that use access to the Database.
My question is: Are there any security concerns around this approach? As far has removing the DB credentials from the connection string, is there a better(easier or simpler) approach we should/could be taking?
If you need to secure and audit access to the production database then Windows Authentication is a better choice than Sql Authentication for a number of reasons:
You can control exactly who can access the database via NT groups and permissions, which means you know who specifically has access to the database. The pool of access with sql authentication is only limited by who knows the password. Given n people who know the password, tracking who did what at a certain point of time is trickier (but not impossible) given that.
Only your sysadmins need know the password for the nt identity with access to the database; in fact, much of the config can be done only knowing the username
Logins and access can be tracked at the domain level far more easily than with SQL Server logins.
What it wont give you is:
Ability to ensure that the developers can't see production data - whoever writes the app can easily include some diagnostic routines to select out data
Ensure that production data only stays in production - anyone making a backup of the production database (say to restore it to a UAT environment for testing) could easily expose production data.
Problems with this approach have already been discussed in other posts; in particular, with ASP.Net applications, you have to consider whether or not you are going to use Impersonation/Delegation (webserver can act as the NT user accessing it) or a Trusted User model (where you configure a fixed identity to access certain resources).
This is further complicated by the IIS version you are using.
If your connection string is stored in a web.config file, you could create a separate production version of that file that the deverlopers can't see. That's easier to test and setup than integrated authentication using app pools.
One word of warning though: If you restrict developers that much, it will slow down their velocity of change. Since the rest of the world does keep moving, this usually ends with the application becoming a dead legacy package. That's dangerous if you plan to grow, improve or extend.
Use of application pool's identity can be quite complicated to set up, consider trust and delegation problem.
A better option can be securing connection strings using encryption.