I am wondering if there is a solution to my problem. As a summary, I need a non-intrusive Web response cache for users that authenticate via a client certificate and are authorised to see URLs based on that.
I have a JEE application and I would like to cache responses to Web requests. I am trying to do it as transparent as possible (ie. without messing with the code), so I found Squid.
My problem is that users might authenticate themselves via a client certificate (or the absence of it) getting authorisation based on this, and this is what makes things "difficult". Is there a way to configure Squid, or any other software, to cache the results after the communication has been established by Tomcat? Something like a cache that is triggered by my application right after the TLS handshake is over and Shiro has been called (because user permissions depend on their certificate). The fact that users have to be authorised by my app make me think that the only way is to create Java code for this, not using Squid or similar software transparently.
I am sure this is a problem that has happened before.
Related
I am having difficult integrating with SSO with my web application.
I have an sample dropwizard application.
I tried integrating with google and facebook open connect.
I thought of 2 approaches for integration
1. fetch the token from frontend js once the user is authenticated using open id, pass that token to the dropwizard server as cookie.
2. fetch the token from the dropwizard server itself and store the set token in cookie while responding to the frontend.
I am not sure on which of the above 2 is best or is there any recommend way of integrating with the open connect in dropwizard?
I like delegating SSO to well known applications/ libraries specific for the job. Keycloak is the application I’m familiar with. But I suppose some of the points below are application independent. This partial answer is a possible direction of a solution, but I don’t think it’s the recommended way, if there is any such way. Some people will dislike the approach.
The front end is responsible for authentication. But it cannot be trusted to be unmodified since it is in user space. Therefore calls to the back end should be validated for validity and authorization (which should be a back end task anyway).
Keycloak has libraries for well known front and back end implementations that allow easy integration. I’ve used it successfully with Angular and Dropwizard.
Integration with various identity providers can be combined. Therefore it is probably a pretty safe bet for a situation where authentication demands are expected to change. It takes some getting used to the extra layer though, so your mileage may vary.
Some links:
https://www.keycloak.org
https://www.npmjs.com/package/keycloak-angular
https://www.keycloak.org/docs/latest/securing_apps/index.html
I've got a Liferay Portal (6.2 CE) with some Portlets (let's say Portlet A and Portlet B)
I'll be called from outside the portal (a third party from the internet) with some params (http://myUrl/myPath?param=X&email=myUser#email.address&info=moreUserPersonalData), and depending of the value of one of those params I need to display one or another portlet. Following the example, if param=A, go to portal page with Portlet A; if param=B, go to portal page with Portlet B.
Some of the params will be sensitive data and I need them to reach the final portlet A or B.
So, I've got different doubts...
Wherever I'll be called, I can decide its technology. I've managed:
A servlet. The main problem is that I cannot share the session between the Servlet and the Portlet, so I can't set there the params. I don't want to send it by GET (it's personal information) and any way to avoid that (like ciphering the data or saving temporarily in a database) looks too much complicated for such a simple task.
A landing portlet. I need to make the redirect with no user action needed, so the lifecycle of a portlet doesn't help me. The render phase (the one called when I land there) doesn't have the redirect method (looks like it goes against liferay's portlets politics) and I don't want to make a javascript autosubmit to reach the action phase.
So, in summary, I need to:
Be called from a third party
Manage some of the data sent by that third party
Redirect to a portlet, sending sensitive data not seen at the url
Decide the better technology to do that
Can you give me any suggestion?
Thanks in advance.
Secure IPC in Liferay
This is mostly a placeholder until you clarify your requirements and functional specifications. I am going to present some security essentials related to the Liferay platform and associated technologies. I will make the advice as general as possible however full disclosure the bulk of my experience is 6.2 EE.
Proposed solution
I think the most obvious way to do this is to have one, or many, web services exposed to clients outside the portal. I would suggest you stay away from trying to accept all the data into a single web service and then routing it accordingly. Instead I suggest you create a web service for every particular end point (wherever you are routing data to) and call that point directly. Your client should be configured to send the data to the appropriate place. However, if for whatever reason you absolutely need to have a single end point to call, then I would suggest you create that end point by registering a jsonws through service builder and then using Liferays internal Spring AMQP bus to route the message accordingly.
To register a JSON WS simply create a service builder entry as follows:
<entity name="Entity" remote-service="true" local-service="true">
In your JSR-286 Portlet that will create the following modifiable files
EntityLocalServiceImpl.java
EntityServiceImpl.java
EntityImp.java
Your EntityServiceImpl file will generate code in EntityService (which will be the service you invoke externally). I generally suggest in EntityServiceImpl you write code that has to do with Liferay's permission checking / resource framework, and once that is successful you then call a method by the same name in the EntityLocalServiceImpl method. The local service method alone should be where you write to the message queue or database.
To invoke your web service you can reference the million Liferay documents online related to JSONWS. Is is just a brief architectural overview, but I have general hardening steps for the entire stack below.
Liferya Tech Stack Hardening
Let's talk about how you currently have your portal configured. I am going to assume you are running one or many Tomcat application containers behind an Apache web server. However, if you are not running these specific technologies, the advice I am giving is interchangeable.
1. Portal Version
Make sure you are at least running the Enterprise Edition at 6.2 or DXP. Verify that your portal is at the most recent batch level for that release branch. I would suggest you go even further and make sure that you have every single hotfix as well (you can be at the highest patched version but still missing a hotfix).
2. Portal Installation and OS
I would suggest your harden your Tomcat server / portal installation by doing the following things.
Install inside a chroot jail.
Owner and group should be a non root user
Run your Tomcat instance with Java security manager, develop a java policy file specific to the needs of that Tomcat instance.
Enable, correctly configure, AND ENFORCE SSL at the Tomcat layer
Override all the default error pages (404, etc). Create a new page to display for any page that returns a java.lang.Exception
Protect your shutdown port
Make sure tomcat doesn't server index pages when welcome page's arent specific.
Changer permission bits on your portal_home/conf folder to 400/read only.
Remove server version in HTTP response headers
Strip and repackage ServerInfo.properties in the catalina jar.
Set secure flag for cookies
Add HTTPOnly for cookies
Make sure that you have iptables or some other firewall that closes all ports from the outside. SSH only from the inside. Only enable port 80 from outside (if its public facing) and drop the rest.
Deactivate the JSP deployment engine
3. Web Server layer
The web server layer will have general security measures similar to your Tomcat instance. It may be much more difficult to run your web server in a chroot jail or with a non privileged account though. It would be nice to have a real, enterprise IPS sitting in front of your web server (or load balancer if one exists).
Enable and properly configure SSL (for best security do this at the app container and web server layer). Disable ssl v2, v3, etc. This topic is way to big for a single bullet point
Remove information gathering abilities by removing/disabling ETag, directory listing pages, server name response headers,
Run your web server from an apache user with apache group (or whatever account you choose). You can attempt to make this a non privileged account but again it might be difficult.
Change the permission bits on the configuration folder to 750
Limit what type of Request methods you want to allow here (you can disable request methods like put, post, etc here). What do you obviously will determine how you configure this
Disable http 1.0
Disable trace requests
Set set your httponly and secure flag for cookies at this layer as well
Enable protection against click jacking, xss, etc.
4. Liferay properties hardening
There are several properties that you can toggle to harden your Liferay platform. Some very obvious ones (and their descriptions):
Always keep the following two enabled
auth.token.check.enabled=true
json.service.auth.token.enabled=true
This relates to the p_auth get parameter you will see in the portal. The client is responsible for generating this token. If your client is outside the portal environment.
If your client is outside the portal environment you can ignore tokens for particular origins
auth.token.ignore.origins=.....
Basically this will allow you to ignore the auth token requirements for particular origins. This is much better than ignoring for all.
I would definitely suggest you forcing HSTS and again filtering based on request methods
jsonws.web.service.strict.http.method=true
jsonws.web.service.invalid.http.methods=DELETE,POST,PUT
# Not necessarily filtering the above methods just an example
To secure the webservice I would likely require basic authentication
basic.auth.password.required=true
With basic authentication you also need to make the specific web service endpoint public
jsonws.web.service.public.methods=.....
Then a this point you need to configure basic authentication and user account on your tomcat/web server.
I would further restrict access to the jsonws page, servlet, and services by using
son.servlet.hosts.allowed=....
json.servlet.https.required=true
jsonws.servlet.hosts.allowed=....
jsonws.servlet.https.required=true
You might also want to check out the AccessControlled annotation
For basic authentication done right you need to look at the authentication pipeline examples.
4. Additional Liferay hardening
In addition to securing the web service I would probably secure your portal by:
Disabling the default administrator account using the default.admin.*properties,
Block the following pages
/c/
/api/
/usr/
/group/
Disable all the default portlets by filtering based on p_p_id
Seriously consider restricting WebDAV Servlet, Spring Remoting Servlet, Liferay Tunneling servlet, Axis Servlet.
Disabling unwanted/unused struts actions
Use JNDI of JDBC
I realize this is basically just a big dump of information without much context but when talking this broadly about security its all applicable. I didn't even touch the data layer because you didnt mention persistence. StackOverflow is more helpful when you do the preliminary research, try to implement a solution, and run into a very particular problem. Hopefully this will put you in the right direction to a more pointed question
Create a website made with SSL/TLS security encryption.
I am creating 3 applications that are written for different platforms (.NET (C#), Android (Java) and PHP). I'm using C# for the WPF application that is going to run on Windows PCs, PHP on the server side and Java for the mobile app. I am using a MySQL database where I'm storing all the information that 3 apps are going to be using.
I am using web requests to my Apache server (JSON and POST basically) when I need some specific stuff to do with PHP.
But, how safe is:
When I'm connecting to the MySQL database via C# and Java?
When I'm sending GET and POST web requests with C# and Java?
Can you somehow spy on the traffic that is going on between the device (PC / Android device) and the server and find out the user and the password of the database, or even get the post request parameters that the app is sending?
Because I know there are a lot of network-monitoring software and I wouldn't be surprised if this is possible.
If it is, then how to avoid it?
"How secure are Java and C#?" isn't quite the right question, because the answer depends on what you do rather than the features in the languages. They both have plenty of good options for implementing various types of security in various ways. What really matters in your case is how the machines communicate.
Can you somehow spy on the traffic that is going on between the device (PC / Android device) and the server and find out the user and the password of the database
Your clients (the PCs and Android devices) should not be connecting directly to your database. They should submit requests to your server, where you have much more control, and can authenticate clients and validate their data. The server then connects to the DB.
If the clients call the DB directly, not only are the credentials transmitted over the internet, but they must also be present locally on the client in some form. This means that someone could potentially crack your app and get access to them.
or even get the post request parameters that the app is sending?
Yes, these can be intercepted and read. Again, preventing this is a matter of how you implement the communication. Use the HTTPS protocol, which you can do in both C# and Java, and the content of your requests will be protected from being intercepted by third parties along the way.
When your traffic is noticed or intercepted it will be freely interpretatable to the reader. You can see an example of such traffic in the console window of your browser, or if you want to view the actual application traffic use a proxy (such as Fiddler2).
If you want to prevent your traffic from being read, you have to take measures to ensure authorization and access control. You can do this by encrypting the traffic with TLS/SSL. If you have web-endpoints you can often enable https trough the libraries configuration. You may need to pass it as a parameter to the code that builds your connection.
Furthermore, it is best practice not to divulge sensitive information in your application output. You will want to use strong passwords and refrain from storing or sending these in plaintext.
I would also advice you to break down the need for securing in smaller bits.
Example:
You are using a lot of different technologies. These all have best practices and guidelines related to security. Separate your applications from your networking/operational assets. Encrypting your communication is a measure in your application. Whereas your MySQL configuration works in a different way entirely, mostly trough configuration.
Why are you connecting directly to your DB from the Android/WPF apps?
If the MySQL DB is sitting on a secure server, perhaps wrap the database calls/services in RESTful APIs implemented in your PHP solution, then call the APIs from your client apps, this also saves you from writing SQL statements and DB specific tasks in multiple languages (Java/C#)
not knowing your situation makes it hard though...
I have a question about whether I really need SSL or not. The scenario is as follows:
I have two applications at the moment, they are both Java webapps. One of them is getting data from another via RESTful web service secured by Spring Security, but my problem is that it sends username and password in URL so the other app can authenticate and authorize it using LDAP. In the end both apps will be running on JBoss AS 7 server so even though one of them is a client and the other one is server they will be running on one server and that confuses me a little bit (even if they will use multiple instances of JBoss they will still be both in the same network). Also signing certificate by third party seems unnecessary here because I don't really care if anyone will trust my server app and again I found that I can implement my own Certificate Authority but it really seems to me as an overkill.
So to summarize it: if I only care about request (or just its parts - username and password) being encrypted do I need to enable SSL and provide all it needs or is there any easier way to achieve it?
I need to connect to a MySQL database from a java Desktop application. The way I was planning on doing this, was using HTTP to open a php page on my website, that PHP script will handle all the mysql stuff so my MySQL user/pass is not accessable to the client at all. so, my question is, would SSL be required? and also, how could I prevent people from taking the URL to the PHP script and using their web browser to mess things up on the database?
This should probably be on the security site, but anyway.
If you don't want everything you send to the database to be visible to the world, use SSL.
Force the client to authenticate to your server side script before making any changes to the database if you don't want anyone in the world making changes.
Make sure that SQL injection is prevented.
Why wouldn't you just use MySQL user authentication with SSL? Writing your own bridge sounds like it would only cause problems and expose more security holes than you'd otherwise have.
so, my question is, would SSL be required?
SSL helps provide a layer of security, through encryption, which keeps people from hijacking the connection and intercepting what you send (for more information, see: Firesheep). Therefore, while not required, per se, it is recommended. If you have control over the Java app, and depending on your purposes (namely, an in-house application), then you can use a self-signed certificate and package the cert with the app for verification purposes (see: this SO question for more info on self-signed vs CA SSL certs).
how could I prevent people from taking the URL to the PHP script and using their web browser to mess things up on the database?
As with other Information Security things, nothing is 100% guaranteed, but the most common way to do this would be via an API key, especially since what you're describing is an API.
If you're looking for a quick-and-dirty setup, then you can use HTTP Basic Authentication to send some credentials, and use SSL to secure it. For a more robust solution, you'll probably want to look into HTTP Digest Authentication and/or OAuth. What you use will also depend on your specific needs.
You can then code the API key into the Java app, or create a way of generating and requesting API keys (again, depends on your specific purposes and needs), and the client sends the API key with the request. If the key doesn't match what you have "on file", then you deny the request.
A quick note on using an API vs connecting to MySQL directly
A couple of people brought up connecting to MySQL directly. I think this is a valid option, but will depend largely on what you're doing and who you're distributing to (and, for that matter, whether you want to open that database to other clients).
If you have plans to have other clients (such as mobile devices) connecting to this database, or if you don't have control of the database for whatever reason (ie - your hosting setup won't allow you to make remote access available), then it might prove useful in the long run to build an API.
However, if you have no such plans, or do have full control of the database, and you control the source code of the Java application, then directly connecting to the MySQL database is a valid option. Just make sure you follow the principle of least access - the Java application gets a dedicated MySQL user that only has the permissions that are absolutely necessary - and the Java application user has a strong password (and since no humans are involved in this process after you code it, you can use a password generator to create something long and convoluted and completely random).