I've written a simple login system with Google App Engine, and I want to make sure that an admin (with access to the whole admin dashboard) can't see the passwords that users are submitting. Specifically, my concern is with the logs. Is using POST's (as opposed to GET's, which are bad for obvious reasons) enough to keep parameters like passwords out of the logs? If not, how do I do that?
Thanks
First of all, you have to make sure that this not very trustworthy individual has a role of a "viewer" in your app. A user with a role of developer or owner can see anything he wants. For example, he can upload a new version of the app (which may not be even related to your app) that will load all passwords from the Datastore and email them somewhere. Or this app will ask users for a password and send it somewhere.
Second, unless you add code specifically for logging passwords (or any other POST parameters), App Engine logs will not contain this information.
You may find this article interesting: Demystifying the App Engine request logs
Related
I'm making a simple java based game and I want to use Google Firebase to store simple variables for the game in real-time.
The only option that Google Cloud supports in Java is to use the Firebase Admin SDK. The one problem with this is that it will leave my service credentials exposed in the client.
I'm honestly fine if somebody gets the credentials and messes up my project, what matters the most is if somebody can get access to my account.
I'm only going to be sending the final project to my teacher and friends. Or maybe I'm just doing this the completely wrong way, if anybody has a better solution that would be great!
Turning over your default service account to anyone grants them the ability to modify pretty much anything within your project, as the permissions granted to it will allow. Since this can vary, you should read the documentation about services accounts:
Service accounts
Understanding service accounts
It is generally a bad idea to turn over a service account to anyone that you don't explicitly trust with your billing.
I'm a bit confused on how I can implement a user system into my application.
For a small overview, the mobile application needs to allow users to login or register, follow other users, and favorite/like items.
I've checkout out the documentation on Google Cloud Platform for implementing User Auth:
https://developers.google.com/identity/protocols/OpenIDConnect
https://cloud.google.com/appengine/docs/standard/java/users/
https://cloud.google.com/appengine/docs/standard/java/oauth/
I've used Parse in the past, and would expect the Firebase User Auth system to offer a similar experience, however due to Firebase conflicts with App Engine, that route is a no-go.
I understand there is also the User API, which can be used for things like restricting Cloud Endpoints calls to logged in users.
How can I roll a user auth system for my application? The best solution that comes to mind would be to just store user emails and passwords in Google Cloud Datastore, and check if the combination exists when a user logs in. However, I'm fairly unfamiliar with creating user systems and this seems like it would come with some sort of security issues.
you can use Firebase Authentication with Google App Engine. Your information that you have to use manual scaling instance is not correct. This was a bug and were fixed. Please see the following post for more informations
Verify Firebase Token at Google App Engine
I'm in charge of maintaining a web application (Lives on a Tomcat server) which has two different access points, through two Apache HTTPD servers which are outside of my reach.
The two access points are meant to log in user either through a third-party SSO system or a good ol' authentication page which prompts for login and password.
The trick is, this SSO puts a limit on the size of files which can be uploaded or downloaded. As SSO users will need to retrieve and send things heavier than that, I need a workaround for this, most likely simply offering a link pointing to the correct resource location through the other server.
What concerns me here is security, in case someone enters a cleverly guessed address to get a document he's not supposed to. The person in charge doesn't want to hear about a SessionManager to make sure the user has the rights to retrieve the documents, but suggested that I could simply use their JSESSSION_ID to confirm their identity...
I am not sure about how to implement this, and have a serious gut feeling that this will backfire in a quite horrible fashion.
Can anyone who had to deal with a similar problem points some of the pitfalls and possibly share a few useful tips on how to securely bypass this SSO ?
One possible way to implement this is to protect the resources on the non-restricted site with a one-time password with a very short life time.
Example:
User clicks on a link to open a document on the SSO protected site. The link should not provide the document directly.
The Tomcat server generates a one time password and redirects (using http code 303) the user to the un-restricted site with this password as an http parameter.
3. When the browser connects to the un-restricted site, check that the password is correct and provide the document. Delete the password so that it cannot be used again.
The password should only be valid for say 30 seconds. You may also record the user's ip-address and validate that.
You should not use the jsession id for this. It is not a good practise to expose the jsession id in a parameter on the address bar or in an html page.
However, you say that the other access point is protected by username and password. If so, will not the user have to log in here anyway? And if so, does not that login protect the resources?
If you provide a link pointing to the correct resource, we need to consider the security.
https://www.owasp.org/index.php/Top_10_2010-A2
The most important thing is XSS and CSRF and solutions are provided in the above website.
Session Hijacking can be another security threat if we provide a direct link which can directly access the resources.
RESOLVED. This question can be deleted by moderators
I have a very simple site written using Java EE (JSPs, Java, Tomcat server). I want to implement a simple login system. I thought I got the registration and login working; however, there is a huge problem with the way I'm doing it.
Let's say Alice logs in. She is able to view her profile with her information, everything looks normal so far for Alice.
Then Eve comes around and wants to log on. She does and is taken to her profile, everything looks normal for Eve.
Then Alice reloads her profile to find that the site now has her logged in as Eve!
So to reiterate: after one person is logged in, anyone is able to go to the site and be logged on to that account. And the most recent person to log on is the active account.
How do you keep track of session information like this so that multiple different accounts can be logged on using the site at the same time?
Thanks!
EDIT:
This ended up being a very simple fix.. I just need to use setAttribute("EMAIL", userId); rather than the stupid way I did it which was just using a global String variable
Rather than try to roll your own security, use an existing framework, like Spring Security. Out of the box, it gives you basic login capabilities and handles securing pages using a role-based authentication scheme.
Reading your problem, I think that you store the last logged user's credentials in an instance variable of one of your servlets. This causes the last person to log in to overwrite everyone's credentials...
If you want a simple authentication, you can use Java EE's provided system :
http://docs.oracle.com/javaee/5/tutorial/doc/bncbx.html
Once a user logs in, put his own credentials in his Http session (request.getSession().put(username, )). Then, everyone will have a distinct profile.
I'm building an app to let users export data from a university system. Currently, they can log in and see the data in HTML, but I would like to let people download it as CSV.
I have an app where users supply their username and password. I would like to log in to the university system and HTML scrape the resulting page. How can I do this?
I'm building a GWT app. I could either do this in Java-transliterated-JS on the client, or Java on the server.
Update: Selenium might be nice, but it looks like overkill.
You're going to have to do this from the server unless the domains are the same. You'd need to determine what the POST transaction used by the other server for the login step looks like - parameter names etc. Then you'd perform that operation and do whatever you want with what comes back. If you need to see multiple pages, you need to maintain the appropriate session cookie too so that the server knows you're still logged in on the subsequent HTTP requests.
If you have to hit another site to validate the credentials, then I'm not so sure that people should feel comfortable providing those credentials to you. That is, if you don't have rights to check the credentials directly, why are you trustworthy to receive them? I know sometimes people need to integrate with a system they don't own, so this is just a question.
First, this has to be done server-side because of the limitations on client scripting due to the same origin policy.
The typical way of handling the "screen scraping" you mention is to treat the web page as if it was an XML service. First, examine the source code of the page, then using an internet/HTTP stack, craft a POST to the correct URL and read the response using a standard XML library. It will take some ingenuity to come up with a good way to dig into the XML to find the piece you need that will be as insulated as possible from changes to the page. Keep in mind that your system can break any time that the owners of the site change their page.
Sometimes, you can't just send the POST but have to request the blank page initially in order to get hidden form values that need to be returned in the POST. You'll have to experiment to find out what it requires.
Additionally, you probably have to handle cookies as well, since they usually are an integral part of the web site's authentication and session management (though you might get lucky that the session doesn't matter between the initial POST and the first response).
Last, you may be unlucky enough that the site uses javascript to do part of the authentication work, which may require additional digging to understand how the credentials are posted to the site.
There are other potential barriers such as the site checking to see that the referrer is their own site, possible use of SSL (HTTPS) and so on.
I'm pretty sure that the protection against cross-site scripting in web browsers will mean that you can't log in to the university's app using javascript running in the web browser. So the part of your program that fetches data from the university will need to run on your server. Once you have the data, you can process it either on your server or in javascript in the browser, but I think it would be easier to do it on the server.
See http://en.wikipedia.org/wiki/Same_origin_policy
I'm not too sure about GWT, but in general, you would take the form data submitted by the user, check it against a database of username and hashed passwords. If the database checks out, set a session cookie that says the user is logged in.
In your pages, check if the session cookie say the user is logged in. If not, redirect to login page, otherwise allow them to view the pagfe.