I am not a programmer, but for some reason I do program here at work to do some apps that makes out job easier. Anyway, this "some apps" has grown bigger in years. I've always had problems in understanding security or authentication related things, so I do it my way (which is indeed way way way far from being right). I use C#, mostly with client/server apps using WCF.
The issue now is in my methods in WCF. All of them are similar to this:
public Employee AddEmployee(Guid sessionID, Employee emp)
{
Session session = Common.CheckSession(sessionID);
// do stuff
}
As you can see, the sessionID is passed to every call to the WCF. This ID is generated once the user login using another WCF method. A row in the database is created and the 'CheckSession', which is called in every single method checks if the session is valid and if the user is allowed and so on. The connection is secured using SSL.
How wrong is this? Can I just keep do it for now? Or should I just stop it because it is so messed up, and start figuring out the right way of doing it?
if you squint your eyes and turn your head to the side a bit, this is kind of how authentication works.
Except, WCF uses an encrypted layer to send messages so no one can spy on your session / authentication / data information
It does a similar check, not per call, but it hooks the calls (which you could do too) right at the beginning, checks the authentication, then passes it on if its allowed to.
Thats just for authentication (working out that you are who you say you are). Security, whether a particular user is allowed to perform particular actions is controlled through things like "Roles". But you may have to build in even more checks if you have more fine grained security concerns.
Now inventing that yourself? Not a good idea. Too easy to have holes your method.
Related
Thank you for looking into this! My boss asked me about the following: We are in a library and we have online access to journals. When someone requests access to a journal, we log them on. If this has to be done for a whole class of students, it takes quite some time.
Let's assume we have a Csharp application. The application is in the C:/Program Files/ folder together with some kind of configuration file that contains the credentials and URLs and so forth. Since the files are in the C:/Program Files/ directory, a regular user will not have access to copy/manipulate any of the files. Using the CSharp SecureString class, the credentials would be safe. However, as soon as the application opens the browser and uses HttpWebRequest to send a POST request to log us in, the data would not be safe anymore.
Is this correct? A regular user can start an executable and could gain access to the POST data in the browser or can maybe impersonate the browser to get the POST request data.
If this is the case, I have two questions. The second one may be a question about opinions but the first one shouldn't be.
Is there any way to do what my boss wants me to do safely without ever giving anyone access to the credentials?
Is this a bad idea and should not be done at all?
I am also happy about "You should not do this, because..." answers, because this would also solve the problem for me if I can convince her of this.
Thank you!
Edit:
Sorry for the lack of information: Different accounts are used. Most of the time, it would be the student's own domain account. We also have a generic domain account we sometimes use in the library for classes to have the computers already logged in when the class arrives to speed things up. So this is a well known account. Of course entering the credentials in front of the patron as we do now is in no shape, way or form secure either.
It is a provably unsolvable problem. Since the user's machine, in your setup, needs to know the sensitive information, there is no way for you to prevent that machine's user from also knowing that sensitive information. The only way to prevent the user from accessing it is to ensure that the sensitive data is never on the client's machine.
Pretty much any "good" solution is going to require some sort of cooperation with the site in question, which you presumably won't have. Good solutions would involve having a server only you control (with the "real" credentials) log in, and then provide some sort of temporary token or session ID to the user to use for a period of time, and that would expire after a short while.
Another option is to never have the user directly access the site, but rather always access a server you control which will redirect all traffic (that you consider valid) over to the other system. While this is an option that would be possible without any cooperation from the 3rd party, it likely wouldn't be terribly trivial to implement.
I'm pretty inexperienced when it comes to working with IIS, so I apologize if the question is a bit confusing.
In the application, I have a Controller with a method called 'Login' that takes in a string parameter. The parameter identifies the organization the user is trying to authenticate against.
For example:
http://mysite1.com/Login/12345
Visiting this link brings the user to a login page for the organization that is associated with '12345' for their access key.
Is there any way to redirect users that are logging in under '12345' to another server? We have a few beta users that are willing to participate, but the database schemas for both servers are different, so it's important that the beta users are not hitting the wrong site.
After the user logs in, the access key is no longer in the URL, so I can't do matches against it.
I'd like for the user to see the following URL:
http://mysite1.com/Login/12345
http://mysite1.com/Products/
http://mysite1.com/Admin/
While in reality they're on a different server:
http://mysite2.com/Products/
http://mysite2.com/Admin/
I have to emphasize that I really do need the URL to stay 'mysite1' for the user, when in reality they'll be on 'mysite2'. Please let me know if this is possible or not, or if there's a better solution for it.
Sorry if this is a confusing scenario or if there's some information that I'm missing. I'll make edits if necessary.
Virtually anything is possible, but this approach seems really painful.
IIS can perform URL rewriting but it's going to be doing this before it hits the authentication layer so it will not be possible to differentiate users at that level.
It seems like the best option will be to write a custom URL rewriter provider. Looks like this post is attempting to solve it that way.
It really seems better to either redirect to a different server (which I know you're saying you can't do) or merge the multiple versions of functionality into a single app (with different controls/backend models, etc.)
This link may help in understanding a little bit about how the flow works in an ASP.NET MVC app.
Based on accepted answer of this post How can I create a product key for my C# application?
I would better to investigate (for didactic scope) what really means with "security check skip" terms.
As far as I know, a simple boolean comparsion can be cracked within 5 seconds, for example:
if(textBoxActivationKey.Tex == "123") ok...else ko. That represents a classic weakness of any secuirty system solution, so what really can be more efficient against simple comparsion?
Somewhere I remeber to have read to use some exception throwing for crash the application rather then use bool comparer, but I guess it cannot be enough.
Granted that (at least theorically) anything can be cracked, how make it really sofisticated secure activation system? Which can be a real deterrent?
Are you looking for efficiency or effectiveness? Most applications phone home. That seems to be a pretty good activation method. However, this means that the user must be online to activate.
If you must be online, and the activation is done through a service (that you own) on a server somewhere, then you can instantly record that the activation key has been used (and invalidate it).
I'm not an expert on this subject, but I think if the shipped key represents only part of the full activation key and the rest must be received from a server, that might work.
I have to implement a payment gateway for a website I am maintaining, and I haven't done anything like this before. Previously to implement payment processing, the site would build a transaction and send it directly to the payment processor and await a result. Since the site handled the gathering of credit card information, building of the transaction, and the requests/responses, there wasn't much I had to worry about that the previous developer hadn't already covered.
Now that I'm implementing a payment gateway, is there anything I should be checking or verifying?
The way this processor works is, I build a form that has the order id, amount, currency, etc. in hidden fields. That form is posted to the gateway, which will handle the processing, and then post a form back to our server where we can update the shopping cart and complete the order.
The only thing I can think of is a user modifying the form fields before we post them to the gateway. Such as adding a $100 item and changing
<input name="amount" value="100.00" type="hidden">
to
<input name="amount" value="0.01" type="hidden">
So when I receive the post I have to verify that the amount paid for was equal to the amount owed. Is there anything else I am missing? The implementation documentation doesn't even mention a scenario similar to the above, so I'm a little worried I'm missing other things and leaving the site open to further exploits.
I think you'd be better off creating a dedicated web service to handle this '3rd party' conduit architecture you have going on here, your basically playing the middle-man and an HTML form just feels like unnecessary overhead to me, unless it's required to be done that specific way, I'd move to a web service.
That being said, treat it like any client application, don't trust whatever they give you, validate and cleanse the information as necessary before performing the operation.
I would also recommend building or integrating support for logging into your middle ware system, so should a problem arise, you have some way of capturing issues and tracking them for the future, bug fixes, support calls, etc.
It's probably obvious but make sure to validate your order #'s, a user could put anything in there they wanted, again, validate and cleanse the data and log the truly weird situations.
First, I have to agree with Capital G. It would be so much easier to just make a server to server connection than to try and handle form submission through the client browser.
One thing to check: after submitting to the gateway, does the client then initiate the post back to your server, or does the gateway server handle it? If the client initiates it, what prevents them from POSTing to you that the order is complete without ever having gone to the gateway? It sounds like you might need to make a webservice request to the gateway to verify the payment actually went through before accepting the client POST that claims it did.
Could you add a digest to the communication? If you had a shared secret with the gateway you could validate the integrity of information shared even if it passed through the client by including a digest both ways.
Make sense?
Carl
First, I don't think you're implementing a payment gateway. It sounds like you're just using one. If this is wrong, just ignore the rest of this answer, and I'll delete it when I can :)
Using a Payment Gateway from a Simple HTTP Form
Google Checkout -- as one example -- allows you to use an "unsigned cart" like the one you describe. The other option is to post via the web service interface, and do correct error checking etc.. When you submit an order with an HTML form, Google Checkout warns you, the merchant, that the "cart is unsigned" (later in the admin screen). This means that the information in the cart -- especially prices -- is not to be trusted. The fact that the end-user put in their credit card basically vouches for the fact that the transaction is okay with him/her. So you just have to check that the numbers used to arrive at the final totals -- or amount owed, or whatever your business is -- check out. So what you're doing is fine on a low-level.
The reason you should use a web-service submit to the service -- and secure signing of the cart, etc. -- is... What do you do if the numbers are wrong? Call the end-user up and explain the situation? So that's a bit tricky, because you cannot assume fraud. There are many strange reasons for which the cart would be altered without the user actually wanting to scam you.
the company I work for want to use a "hosted payment form" to charge our customers. A question came up on how we can populate the "payment form" automatically with information from one of our other system. We have no control over the hosed payment form, and we have to use IE. Is this possible at all? And if so, how can this be done?
If something is unclear, please let me know...
Assuming that you are essentially embedding the contents of a remote form in a frame/iframe, the you should be able to use some javascript to set values for the fields - field.value = "xxxx".
That solution of course depends on the form remaining the same - any changes to the remote form will require you to update your script.
If you are "handing off" to a remote site (redirect) that post's back to your site when payment is complete, then unless the remote site offers an API / a way of passing request parameters through, then you are going to be out of luck,
Unless your payment gateway allows you to pass through data in a set API (which lots do!), you'd need to take control (and responsibility) for your payment form.
I say responsibility because you would have to prove to your merchant account provider that everything is secure. This will probably incur some security testing fees too.
So check with your merchant gateway first. Lots of systems have the means to accept data from your site and their tech support will be able to give you a straight answer immediately. Otherwise you'd have to switch it over so you process all the data yourself which, just for making things easier, isn't worth it IMO.