I am making a web app that has a login page (Using Facelets with JSF 2.0) which checks credentials before redirecting to a isLoggedIn or error page. I have access to the server
that the app is deployed on and Tomcat is used as container. I would like to log ip addresses that clearly tries to perform brute force attacks. My idea for now is the following, but I am not sure how to get hold of the offending IP and even if I could it looks a bit clumsy, so what is a standard/good way of doing this? I would prefer not having to use
any other implementation of JSF.
During login write log messages (from Beans) using a logging framework to an app-specific
logfile in Tomcat's log folder where failed logins are saved with offending ip and time.
Create script that reads the log and checks if any ips have a high rate of failed
attempts. Add these ips to hosts.deny.
If you're using realm authentication check Tomcat's LockOutRealm. It does not write the host.deny file but it also could prevent brute-force attacks.
Related
It's not a common question, but I wonder if any tricks or upcoming standards exist.
Belows are a flow and what I want to implement.
Web application loaded from server-side
Client-side script loads some secure contents (not from #1) that need to be protected from web application provider. It could be shown to a user visually.
Web application provider knows where are the secure contents (in Dom path) and possibly may try to catch it by putting a script
However the secure contents shouldn't be hijacked from servers (even from the same origin) or from external application (even from developer tools if possible)
EDIT:
For better understanding, it's for use case where web application doesn't hold user data in their DB but loads the data from somewhere else. In case, I need to protect the data from web application, which is uncommon in regular web application.
You should use a content security policy (CSP) which would enable the browser to deny injection attacks. These can be a little tricky to setup correctly so I would use Report URI to help you get it going. The trick is to use report only mode first until you have validated the settings then switch to enforce.
Very strange issue I am facing from past few days. I am just able to login to any application on my domino server using "Mozilla Firefox". If I use any other browser (Chrome, IE), it just stays on the login page with absolutely no information, everytime I login in it again shows back the login page with no error message at all. Its quite strange since its working perfectly fine on Firefox.
I am not sure, but I somehow feel that it has something to do with the configuration. Would really appreciate if someone can guide me here.
Edit 2:
Selecting Single Server, does work, that was the simplest solution; as of now we do not need "Multiple Server".
However, we do not use any other "Internet Sites", I tried to remove the organization field, however, that lead me to "An R5 web SSO configuration already exists", which in turn lead me to here. However, I am able to move further here with "Multiple Servers".
Edit 1: Based on the answers, here are the things I tried. Please find below the snapshot of each of it for better understanding..
LTPA Token Configuration
Server Configuration for LTPA Token
Network tab - before login
Network tab - after login
Console shows nothing before or after login, neither does the server log files. Also, I am able to access the names.nsf database with absolutely no problem. Lastly, I try to access a database with no anonymous access and hence get redirected to the login page (however, as question mentions, it just stays in loop)
Ok, you may need to provide a little more information.
Are you doing a "normal" login using domcfg and a "...&login" url? Or are you trying to open a design element in a database that has no access to "anonymous" and thus redirects to the login?
You can easily check that "standard" login by opening the url: http://yourserver.com/names.nsf?login. Does it behave differently in the browsers? If not then your server setup etc. is Ok. Then you have to look at the solution that tries to log you in.
Your first place to check is in the browser's console. Are there any errors in there? E.g. some client side Javascript that stops running? Check the network tab when you inspect the console/developer tools. Does it send the right requests?
Another step is to check the console/log files on the server. If you have grown your own solution then you may want to add some simple print statements to prove that it sends what you think.
Finally, you can use a network sniffer (like wireshark) to see exactly what is sent between your browser and the server.
/John
A login- page that reloads itself after every login without a message like "Wrong username or password" or similar normally happens if the session authentication for the server is configured as Multiple Servers (SSO) (Found in Server document on Internet protocols-Domino Web Server, if Internet Sites are Disabled or in Internet Site document, if they are enabled).
In that case an LTPAToken has to be configured as well, and this token has to have a configured domain name. Whenever you try to access a server with SSO enabled using a hostname without domain or with a different domain, then exactly this will happen: Login- Page reappears after every try to login.
Example:
if the servername is myserver with ip 10.10.10.1 and the LTPAToken is configured for ".mydomain.com", then the only valid URL for login is:
hxxp://myserver.mydomain.com
Trying hxxp://myserver or hxxp://10.10.10.1 will result in exactly the described behaviour.
It is important to know, where to look for the "right" SSO- Configuration document.
If the server is configured to use "Internet Site documents" (Server- document, Basics- Tab, Load Internet configurations from Server\Internet Sites documents enabled) , then the SSO- document needs the field "Organization" to be filled. In that case you will find it in the Web\Internet Sites- View of the domino directory.
If Internet Sites are disabled, then the Field "Organization" has to be empty. In that case you find the SSO- document in the Web\Configurations view.
I am using an xPage as an iWidget in IBM Connections 3.0.1. I have extended the ajax proxy to point to the nsf. During testing everything was working correctly but I realized it was only working when I was already authenticated with the application (I do use SPENEGO to auth). When I load connections in a fresh browser session I get the BMWIW0001E:Unable to load iWidget error. But if I load the app then reload connections all is well.
Is there a way to pass through the user's credentials or otherwise prompt for a login?
Is there a way to hide the "BMWIW0001E:Unable to load iWidget " error and display a custom error page?
The error message is generated afaik by connections, so you might be better of asking on Server fault or the IBM Connections forum.
For authentication in a mixed environment you have to sort out the trust relationship between the servers. Pick your poison: LTPA, oAuth, not sure about spinego.
As a short term remedy you could use a landing xpage in your widget flagged for anonymous access (allow public access and in the ACL: anonymous with no access but read public access.
In that page you check #UserName and redirect to a mini login or the real widget page. Redirect can be also by loading a dynamic control
I'm currently searching the best way for developing my next webapplication. I'm thinking about using Backbone.js and build a single page application. But I really can't imagine how to secure my app since nearly everything is done on client side. Of course I just could prevent the users from accessing my RESTful Api so they would not have access to my data. But all the view/model/collection/template js files are still accessible.
Or is there a known way to serve the js files with php (laravel), which would allow me to only serve the files I need for the respective user.
I just couldn't find a solution by searching the Web. But I just don't think that I am the lonely person who needs a clean and secure authentication method including different user rights.
Thank you in advance!
Your backend application will fetch data from a backend (= API), and probably send back some changes.
This code can't have "security holes / leaks" as long as your backend is secured.
If you are afraid of people stealing your code, you can always minify the JS (check grunt.js and almond.js for this)
To secure your backend you can make use of Laravel's auth class, and the auth filter as mentioned before.
Besides normal auth, you could implement roles, that you can assign to specific users, giving them more or less access to certain resources in your backend.
Here's the method I would try :
Separate the application in two parts.
One part - login via regular Laravel Auth on a separate page, and then when the user is logged in serve the single page app in a different view.
Wouldn't this work?
Web Services are no different than any other web application you build. At the end of the day you are exposing functionality to the client (which is also the attacker). It doesn't matter what the client is implemented in, if you expose dangerous functionality you will be hacked.
Have a session state, keep track of the user id and make sure that the user is only accessing resources they have been allowed to access.
I do not think that what JS/template files are exposed really matters. Essentially, you should only be allowing data interaction to authenticated users. Think of this as two separate applications.
The front-end application logs in, and a cookie is stored (or some other persistence is used).
The back-end application then uses the persistent authentication to validate every single user request for data, and every user action.
This way you don't have to worry about the security, the client can only fetch the data that the server allows it to, and, likewise, it can only interact with the data insofar as the server allows it. You shouldn't be relying on the client side for security anyway, even logged in, otherwise some malicious user could, conceivably, save all your frontend code and use it against you without authentication.
I currently have a very basic cluster composed of two Tomcat 6.0.32 instances (Tomcat1 and Tomcat2) running on the same VPS. I'm using mod_proxy_ajp and mod_proxy_balancer as the load balancer through Apache (on the same VPS).
We are using basic form authentication (via j_security_check) to create authenticated sessions for users.
The load balancer is working well and unauthenticated sessions are being replicated between the two instances successfully. However, I am unable to have authenticated sessions replace between each instance.
I am using a very basic JSP called session.jsp (based on the JPS template http://www.syslog.gr/articles-mainmenu-99/15-tomcat-cluster-session-replication.html) to test the session to see if it is a new session and print out the JSESSIONID. I have one copy of the JSP inside of the protected area and one copy outside of the protected area.
I've run the following tests:
Test 1)
I access session.jsp outside of the application's protected area on Tomcat1, I note down the JSESSIONID and confirm with the load balancer that Tomcat1 handled the request. I then shut down Tomcat1 and refresh the page. The request is now handled by Tomcat2 (as confirmed by the load balancer). When the page finishes loading I see my original JSESSIONID and my session has survived.
Test 2)
I access session.jsp inside of the applicaton's protected area on Tomcat1. This prompts me to log in. After logging in I am sent to session.jsp and note down my JSESSIONID and confirm with the load balancer than Tomcat1 handled the request. I then shut down Tomcat1 and refresh the page. The request is now handled by Tomcat2 (as confirmed by the load balancer). When the pages loads I check my cookie. I now have a new JSESSIONID and I am once again prompted to log in.
So far from this I've figured that authenticated sessions aren't being replicated like unauthenticated sessions. Is this a good reason for this or does it point to a configuration problem?
You have not running on sticky_session mode and it could be enabled with worker.loadbalancer.sticky_session=1
And bettter check : http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html