I've been working on a django Web app to manage some data for tenants. Things like their personal contact information, government ID, tenancy agreements etc (in other words, very gdpr sensitive info) as well as personally private information such as expense reports. All of this is displayed on the front end of the app as intended seeing as it's supposed to be a private tool for internal company use.
At the moment I run it at home on a local machine server so there is little risk involved however for my convenience I'd like to take the Web app live so I can access it while I'm out and about. The issue I'm having is that there really is no reason for anyone other than myself or business associates to use this app and therefore no reason for anyone else to connect to the domain.
I've considered making the landing page of the website a login page and locking all other views behind this with CSRF protection but even that is too close for comfort in my opinion as it would mean allowing external entities tor connect to the app. I'd much rather have a server which refuses any connection to the outside world straight away unless it is from me. In other words, a server which does not divulge any part of the app or database until login credentials have been correctly entered.
What I envision is that once you type in the domain and hit enter, the moment a connection is made, the server prompts you with an alert box asking for login credentials before any of the app or templates are loaded.
Is this even possible? I've never hosted any of my software online and do not want to fall into a nasty data breach situation by taking this live. At the same time it isn't ideal that the current system operates on the premise that I'm home all the time.
Related
I've made quite a few web services over the years, and all of them had admin pages, which either could only be accessed by users with proper roles or all together different "admin accounts".
In all the cases, I made some scope in the main project, and made sure non authorized users couldn't access the pages, it works fine.
However I always had the urge to completely part the entire feature into another service, or even create a minimal desktop app that would access restricted APIs.
I know its pretty much pointless overhead to do something like that, but in such instances like having two developers working on the main site and admin site, or security demands that there are to be no browser friendly way to access administrative features, or well just for the sake of it, I was wondering if there are any cases that the administrative pages have been separated from the main web service.
Any examples or design patterns on the subject are welcome.
I have an Django application at my work, only available on the internal network.
Currently we import data using Excel, but this is a terrible error prone process and I want to replace it.
I would like to provide a rich web application in Javascript which exposes some, but not all of the data from the main Django application (lookup values for menus). This would run on a server visible to the outside world.
So what is a good approach for this?
Management are concerned about security of making the main Django app available to the outside world, and I would prefer an intermediate tier as well - I think it would be easier to write a small server side app than to go through the current code and make sure it is secure enough to the outside world (I learned Django buildiong this app, so some of the older code is not done according to best practices, but does work as it needs to). I would also like it to hold the new data until someone has checked it looks OK before importing to the main database. (I am the only developer, so there are time considerations).
So two options I can think of just now.
1: Have a small Django app on an external facing server. This can communicate with the main app to get the values required for lookups, and store the input before it gets imported. The tables will essentially mirror the main app and need updated when the main app tables change.
2: Have something similar, but rather than use a database, use the external facing server to contact the REST interface on the internal server. Something like using Django non-relational to get data from the REST interface of the main app. Put an import table in the main database server to store the dats for approval.
Are either of these good / bad approaches?
Any other suggestions?
Are there any good resources for learning about n-tier apps?
If I understand you correctly you want a small Group of trusted users to be able to access an internal database. There is already an Internal Django App accessing that database.
Management is concerned about making this app or an extension of it available to the general Internet.
I think ther concerns are very valid. If you have only a limited set of users accessing the import functionality, push authentication out of the Django Web Application into the HTTP Server / Balancer / Frontend.
For example set up an apache external webserver forcing all access to your Django App beeing encrypted (HTTPS) and authenticated. Users can be authenticated via HTTP-Auth using static files on the server. Password changes / user additions have to be done by an admin logging into the server.
Only after completing this login the Django App with it's own authentication can be accessed. I would opt vor a smale seperate import App instead of extending the main app. This small app could run with reduced permissions on the main database for an defense in depth aproach.
This setup provides you with a litte additional interfaces / points of failures, while maintaining a small attack surface against random Internet users. You can hire a security consultant th audit your apache config and be assured that you locked out the greater Internet and only have to worry about HTTP-Authenticated users.
I have benn running such setups for 15 years by now. Users are annoyed by the double authentication and password saving in Internet Cafes is an issue whith HTTP-Auth but generally it is verry seamless if once set up.
My team and me are currently working on quite a large project. We are working on an online game, which will be accessible (for the moment), in two ways:
-Via a web browser, an application full JavaScript(client-side), full Ajax (basically meaning that the UI will be managed in JS client side).
-Via an iPhone application (the UI will be managed by the application itself).
Between the two different applications, the core logic remains the same, so I believe (I could be wrong), that the best solution would be to create a web service (if possible using standards such as RESTful or Rest) capable of perming all necessary operations.
Following this logic, I have encountered a problem: the authentication and identity management of the user. This poses problem as the applications users need to be authenticated to preform certain operations.
I’ve looked into WS-security, but this obviously requires passwords to be stored, unencrypted on the server, which is not acceptable!
I then looked into Oauth, but at first glance this seemed like a lot of work to set up and not particularly suited to my needs (the way that applications have to be accepted does not please me since it will be my application and my application only using the web service, not any external application).
I’ve read and heard about a lot of other ways to do what I want, but to be honest, I’m a little confused and I don’t know what information is reliable and what isn’t.
I would like to note that I’m using symfony2 for the backend and jquery for the client side JavaScript.
Furthermore, I would like a detailed, step-by-step response, because I really am confused with all that I have read and heard.
Thank you for your time, and I hope someone can help me as it’s quite urgent.
Good evening
I'm not entirely sure if this answers your request, but since the UI will always be handled on the client side, I think you could use stateless HTTP authentication:
This is the firewall in security.yml:
security:
firewalls:
api:
pattern: ^/api/ # or whatever path you want
http_basic: ~
stateless: true
And then the idea basically is that on the server, you use your normal user providers, encoders and whatnot to achieve maximal security, and on the client, you send the HTTP authentication headers, for example, in jQuery:
$.ajax("...", {
username: "Foo",
password: "bar"
});
Please note that since the authentication is stateless (no cookie is ever created), the headers have to be sent with every request, but, I figure, since the application is almost entirely client-side, this isn't a problem.
You can also check the Symfony2 security manual for further information on how to setup HTTP authentication. Also be sure to force HTTPS access in your ACL, so the requests containing the credentials are secured (requires_channel: https in your ACL definitions).
I have completed a project here I used Html, CSS, Javascript, Jquery, Ajax and Php. I launch my project into a ISP Provider Company. But I worry about my project. I want that ISP Company or anyone can't access my code and Database. Is there any way that helps me to protect my code and database. Thanks
You cannot secure code running on enemy hardware.
Period.
There is nothing you can do to stop an attacker with administrative privileges.
You shouldn't even rent space from an untrusted provider. An attacker with hardware access can melt the case and add a logging device between the RAM and the CPU to see all data on the server. (I don't know how practical that is)
If you don't trust your host, switch to a different host or run your own data-center.
you can use some obfuscator like http://www.red-gate.com/products/dotnet-development/smartassembly/?utm_source=google&utm_medium=cpc&utm_content=unmet_need&utm_campaign=smartassembly&gclid=CPq4uMC4nq0CFVBTfAod_x-umw
not sure How you save database?
Suggest use your own servers.
The two web service(rest) are running on separated JVM instances with its own authentication.
The services is used by external user's log in, the server2 is for customer service team. After external use log in, he can call server2 for query. Oppositely, after customer service guy log in server2, he also can call server1 to change external user profile.
In another word, these two services trust each other. It seems like a SSO between them. Since both of them run on internal environment, I am wondering if there is a simple solution to implement it.
Thanks
I've had a good experience with JOSSO:
The setup is relatively simple (gateway and partner applications)
Non intrusive (no big changes needed for your application to work with it)
Based on JAAS
Supports various stores (LDAP, XML, DB...)
Works with Java, PHP and ASP (we use Java and PHP at our company and it works flawlessly)
You've got a lot of different options:
You could roll your own authentication system. It'd be exactly what you need, but you get to debug it yourself.
You could deploy Kerberos. A little old-school, but it clearly differentiates login servers from trusting servers.
If you're already in an MS-heavy environment, Active Directory might be just the tool.
OpenID is the new kid on the block; as used by StackOverflow :) but implementations of servers and clients might be harder to find.
LDAP is an easy way to get site-wide directory services; actually doing authentication against it might be a bit more work. (Which is why Active Directory is as popular as it is -- combining LDAP with Kerberos into one mechanism for site-wide authentication and authorization. Neat.)