We've got user SSN's in jsp's that show in source code of an html page as:
<a href="onclick:submitsomeform(123456789)"
In order to avoid this, I made couple of methods called getEncryptedSSN() and getDecryptedSSN() which could be called from the JSP. These methods made use of the javax.crypto to encrypt/decrypt the ssn string, however, this import is "disallowed" by the setup coding standards. So now I'm out of options on how to avoid showing the SSN in the view source of HTML. We can not go the route of not passing the SSN in form submit because in the DB, the SSN field is the only primary field.
Are there any other ways to simply encrypt/decrypt a string in java w/out using javax.crypto?
Obviously, having an SSN as a primary key is bad -- but you may not be able to change this.
Have a look at this OWASP page: Insecure Direct Object References:
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
I have used the Access Reference Map from their ESAPI -- it was pretty straightforward. Our unique IDs were simply replaced with random strings, which were tied to a user's session.
One obvious option is to just write your own encryptian function. You probably aren't going to write something as secure as the big-time security folks have come up with, but depending on the context, something simple might be adequate, i.e. something that would frustrate the casual snooper, and accept that if the CIA or Mosad or whoever is trying to crack your encryptian, they'll figure it out in minutes. I don't know how big a target you are for hackers. If you're working for a bank or the IRS or something where lots of people might well be trying to intercept your transactions and the consequences of interception are high, forget it, you want industrial-grade security. But if you're working for Joe's Pet Care Advice Swap Forum and there's no particularly sensitive information involved other than the SSN itself, and there's no great number of enemies out to get you, a home-grown solution might be adequate.
You should be encrypting your SSN on the database side due to its sensitivity. SSN should not be stored as plain text values because they are fully visible for hacker access. Look at SONY, and the many more companies getting hacked.
I would say encrypt them in your database using database encrypt functions. I don't know what database you are targeting MySQL or Oracle or etc). You then can just use the encrypted SSN from the database. Here is a mysql reference:
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html
Related
talking about the authorization_code grant type. In authorization end point of the OpenID Connect provider we gave an authorization code to the relying party and then they makes a back channel request(no browser involved) to the token end point with this code.
so the question is , How to distinguish this user at the token end point?I guess no session exist for this call since its a back channel request.
What methods can be used to identify the user. could a stored HashMap in memory with key as authorization_code be the ideal solution
Storing it in a HashMap is a solution that does not scale, as internal memory is not shared accross server nodes.
You'll have to store it in some form of persistent store
a SQL database
a NoSQL database
a key value database
Note that you'll not only need to be able to determine the user, for which it was made, but also the client, as clients don't need to authenticate themselves to get a code. Also know that you'll need to be able to determine which scopes are covered by a given code, and to detect double usage of a code, and in case of double usage, to revoke associated access tokens.
On the other hand, you need to be able to easily forget the codes again. They're short term use, and it's no use keeping them around after their ttl.
You'll have similar requirements for storing the access tokens, refresh and id tokens you produce, so it'll make sense to build something which can also be used for those.
I have a login page which connects to a Database, the Database has only one client, when a user logs on he/she may make certain changes to his profile and then save. A large number of frames require the current user id in order to manipulate his data
Among the possible ways of storing the user currently logged in is
1) to save the data to a temporary text file and persist it before the user logs out
2) another option would be to use variables across all the frames ,however I'm not too confident about this
3) a third way would be to have a Boolean column in the database and to persist the the data of the field with true in it
Perhaps there are better ways of storing the current user Id could somebody elucidate other possible methods and highlight the pros and cons of each implementation with reference to an "optimal" method of doing this
Edit: This is a desktop application
I would suggest not to share this information in any static context for the reason it will render your project as very hard to test once it gets big enough. See this link for more info: When to use singletons, or What is so bad about singletons?
What I would do is store session objects in some map, identifying the appropriate session by an ID that will be given and sent back to you via client cookie. This is how the web has been doing it for years, and it is still doing it this way. Simply pass the session object around to any class that requires access to that data when it needs it.
If you are using a J2EE implementation, then you may already have support for sessions within that implementation, you should check out "How to Use Sessions"
This is more of a software design question, and covering the basis to complete the patterns used to support what I just suggested is unfortunately beyond the scope of the question
The logged user is an instance of the class Person or LoggedUser.
You have to instantiate it and share its reference between Views via a Model.
i need some suggestions in designing application, in my application there will be insurance cases and according to roles users will access the cases and different level of life cycle of the Case.Here i need to restrict users to access same case.If one user is accessing one case with caseid (123) and other user should not able to access same case(123). Please can anyone suggest how can i achieve this.
You need some kind of locking. Depending on your specific requirements there are different ways to accomplish this.
For web applications you can use this algorithm which uses a table to store locks and ajax to refresh the locks as long as the user remains on the edit page. The algorithm can be used even if you don't use PHP on the client.
Following is one way of doing this
Make provision in the database (add a column) to indicate that, that particular case is being accessed.
When a user access a case, check the database field if that case is already being accessed, if not update the database field indicating the same.
If another user, tries to access the same case, then based on the database field value appropriate response will be send
Its important to note that the transactions mentioned in #2 i.e. database read and update should be ATOMIC.
The way you are planning to implement locking is not a good practice. I am not sure about my sql but if you are using microsoft sql or oracle then the best practice is to implement optimistic lock mechanism.
The link given below should help you understand better.
www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application
I've been always trying to avoid using Sessions. I've used spring security or other ways of having user logged in the application, which is I suppose the major use case for using Sessions.
But what are the other use cases ? Could you please make a list of those most important ones ? How come that I've been able to develop even complicated applications without using Sessions?
Is it because I'm using spring-mvc and using Sessions is practically not needed except the login stuff ?
EDIT: Guys this question was asking for use cases... Most of the answers explains what are sessions for. If we summarize some usecases, we can say for sure, when to use database or sessions for maintaining conversation state...
Don't you remember any concrete scenarios you needed sessions for? For past years :)
for instance some conversational state may become persistent after some point / event. In this case I'm using database from the beginning.
I think you can do anything you want without storing anything on a sessions.
I usually use the sessions to avoid having to pass state between the client and server (used id as an example) and when I don't want to send sensitive information to the client (even in encrypted form) as it might be a security problem.
Other ways of avoiding using the session are:
store some state on a database, e.g. shopping carts, instead of in the session, even if the cart is discarded after a certain amount of time.
store state in cookies e.g. for user customization
One use case when it's really useful to use the session is for conversations, although usually frameworks manage that behind scenes, and store the conversation in the session.
edit
Converstions (in my understanding) are something like wizards, in which you complete several forms in different pages and at the end you perform the action. e.g. in a checkout process, the user enters his name, shipping address and credit card details in different pages, but you want to submit the order just at the end, without storing any intermediate state in your DB.
By sensitive information I mean, imagine in the previous example, once the user sent his credit card details, you shouldn't return that information in any format (even encrypted) to the user. I know it's a bit paranoid, but that's security :).
In the ecommerce system i'm working on, there is an external system at the back-end which stores users' saved shipping and billing addresses. Our web app talks to it by making web service calls to retrieve those addresses. When we get the addresses, we store them in the session. That way, we only have to call the service once, when the user firsts looks at their addresses, and not every time we serve a page which needs address information. We have a time-to-live on the addresses, so if the addresses change (eg if the user telephones the customer service desk to change an address), we will eventually pick up the fresh ones.
It would be possible to store the addresses in our database, rather than in the session. But why would we? It's transient information which is already stored permanently somewhere else. The session is the ideal place for it.
Well in one sense your question is deep (what's SPECIAL about a session is worth knowing) and in another sense it's shallow (what can't I do if I don't use them turns out to be a somewhat odd question)
In the end a Session is merely (or could be) a ConcurrentHashMap (in fact it usually isn't that threadsafe) with a a key of unique session id passing as the cookie. You know why it's useful, but to answer you for use cases
clustering (this is how state gets distributed across nodes)
caching general state of the user and their objects (as opposed to reloading from db each time)
built in methods for sessionlisteners to watch when someone is timed out, or attributes change.
= used for by a lot of localization utilities
Can you do all this with a database or your own hashmap implementation/filter? Of course, there's nothing magical about Sessions. They are merely a convenient standard for having some objects follow a logged in user and be tied to the lifetime of that user's use of the application.
Why do you use Servlets? You could also implement your own socket level standard? The answer to that is using standard apis/implementations provides convenience and other libraries build upon them.
The cons are
you are reinventing the wheel and some code that has been time tested
you won't be able to use a lot of built in facilities for monitoring/managing/clustering/localizing etc.
Sessions are one way of maintaining conversational state across multiple requests (e.g. multiple stateless HTTP requests.)
There are other ways of implementing conversational state, for example, storing an authentication token or some suitable conversation id as a cookie and maintaining a store of conversation id to session state. (In essence, duplicating what the app server is doing when it provides sessions.)
That you haven't needed to use sessions means that your application either doesn't need conversational state or you've implemented it in a different way. For example, perhaps your application uses an authentication token (say a cookie) and persists all state changes to the database. With that kind of arrangement, there is no need for a conversation state.
Hi you can take an example of shopping cart because since Http is stateless protocol it does not maintain the status of the user who sends the request.
For e.g.
If one user sends a request to buy camera from say eBay and after some minutes another user sends a request to buy laptop.
But since http is stateless protocol so server is not able to separate the request send by the users and may it happen that the bill of the laptop may be given to first user.
So through session we can maintain a particular entity over the server side for a particular user.
I am using the Key value of entities in my datastore as the unique identifier in the URL for pulling up a record:
http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ
This is not a very attractive solution, nor is it SEO friendly, but it's the easiest way I've found to identify an entity uniquely in App Engine/Java.
My main concern, though, is whether there is any security concern related to displaying the unique Key value for the entity?
The encoded key contains your app ID, namespace (if any), entity kind name, and key name or ID. There's two possible issues here: the disclosure of that information (probably not problematic), and the fact that you're accepting an encoded key. If you don't check that the entity specified by the key being passed in is of the correct kind, and that the user should have access to it, then they could pass in their own key to cause you to disclose information you shouldn't.
Almost universally, however, you already know the kind name of the entity you're fetching, so a much better idea is to use just the key name or ID of the key, and construct the full key on demand. This also makes for much cleaner URLs.
The security concern is that a potential hacker knows something, however small, about your database.
If parts of your database are ever compromised the entity id could prove useful for the hacker.
Like you I don't really like displaying database IDs but IF you secure your application properly it isn't worth worrying about as knowing the entity id isn't going to be useful.
Are you sure that's an actual key? It doesn't look like one (the un-base64'd data generally includes your app identifier, for one).
The documentation covers it, though:
Note: A string-encoded key can be converted back to the raw key data. This makes it easy to guess other keys when one is known. While string-encoded key values are safe to include in URLs, an application should only do so if key guessability is not an issue.
It's a lot cleaner to do something like this:
foo = FooModel.get_by_id(int(foo_id))
That doesn't stop attackers from guessing IDs, but at least it doesn't fool you into thinking that IDs are "opaque" (and you can trivially change the ID to test access control, instead of needing to mess around with base64-protobuf-encoded data).
This is not a security concern in my opinion. Lots of sites use id as identifier within the site. A key is just a key to a row in a database table, you do want to refrain from showing much detail about your database in terms of table and user accounts etc.
In this regard, you want to prohibit your site from dumping out database errors when they occur, catch them and handle nicely.