This may have already been asked before but I did not see it anywhere.
Essentially, what I'm looking to do is to have a small C# app (EDIT: or BHO) run and detect when IE (8 or higher) has been launched by a user. Once it has launched, it needs to just sit there until it notices that an authentication challenge popup has been presented from within IE. It would then hide the IE popup and present the user with a custom authentication popup. This new popup would then pass the entered credentials back to IE for authentication.
The app (or service) would cache the credentials and pass them to any further authentication popups received on a local Intranet. So, this is a sort of custom quasi single sign-on solution.
Before people start suggesting changing settings in IE or on the server(s), please know that this is not possible. The above explanation is exactly what we need to do. I don't like it either.
We currently have a small in-house utility written in C++ (not .NET) that handles this exact identical behavior very successfully, but the source code is no longer available for fixes/upgrades.
Anything would be helpful. Thanks all!
FYI - Just saw the first comment. No, this is not a type of malware, pwd spoofer, or similar. The employee gets a customized, company-logo'd credential pop-up to handle everything. The purpose of it is to handle multiple different types of authentications (some are custom) specific to the varying sites within our Intranet.
I finally found and decided upon a solution that is already working as a prototype (very limited prototype). There's still much work to be done, but at least there is light at the end of the tunnel. If I head a different route or receive better suggestions, I'll be sure to update this information. For those whom might ever need something similar (doubtful), here's essentially what I'm doing.
Browser Helper Object
Instantiated with each new IE instance.
Registers with IE to receive events and new windows/controls being created.
Hooks to receive descriptions of controls for logic to decide what to do.
Handles to each authentication dialog windows or control.
Handle to UIAutomation COM to inspect requesting server and realm.
Multi-threaded support capable of thread blocking.
Encrypted credentials cached in memory.
.... and a whole lot more.
I hope that helps anyone needing to do the same. Thanks all for any assistance you could give. I guess everyone is as much of a noob with BHO's as I am.
EDIT 2/14: This is indeed the answer. I have the BHO working as desired. There is still some very minor tweaking to accomplish. (Actually, it's not that minor but it's working.)
Honestly this concept is dangerous. You are side-stepping the security model of the operating system to accomidate lazy users.
The other problem is that your architecture is fragmented. If you have tonnes of workstations across a big organization that don't use a proper platform for unified authentication (Such as AD / LDAP / Etc...) then you're going to run into a very-hard to maintain mess.
What you're doing here is plugging a hole, you're not fixing the crack. I strongly suggest you use this lack of source-code to keep "patching" the system together as the catalyst for change.
If you're so hell-bent on keeping the infrastructure as-is, then you should look to tested & proven software solutions to help aid in keeping things sane for your users.
Take a look at a FOSS Application KeePass. It will allow you to store your passwords securely (a problem your proposal would have to address anyway) and you can have your users store thier DB on a USB-Stick they keep with themselves at all times. They can log in once to thier KeePass DB and use the Auto-Type hotkeys to enter thier passwords in the various login boxes they are prompted for. This can work for more than just IE authentication requests, it can do all your applications.
The nice part about this is you can get people to use relatively strong passwords as they'll only have to remember the one (KeePass DB).
Ultimately you're going to run into issues trying to catch Authorization Challenges, even your existing solution is probably doing it in a very hack-ish way and you're going to find it increasingly hard in the future to continue this behaviour. This is mainly because it's an "IFFY AT BEST" solution, and will likely be made harder to execute as security matures.
Related
Alright so this is about a game, but more generally this can probably be done for all games, I just want to figure out how the application accomplishes it.
So it's for a game called League of Legends, huge game, has an executable file and a massive LoLClient where you can view all data specific to your account, you can queue for games etc.
Now what this app does (that I've came across) is it logs into the league client, grabs all info related to the character and logs out) but it does this without even displaying the client on the users screen, how is this possible? bare in mind it isn't using a server.
A broad question perhaps, but I'm sure there's a straightforward question (app developed in C#)
Riot has a Json API for devs to use and poll their servers for information they need to create websites and applications. It's not even touching the client; if it is, the dev of the app is either a little slow or scraping more than just 'champion information'.
In general if an application from an untrusted source is asking for login credentials, do some research and figure out why - after that use your best judgement. With that said, in most cases, if it is asking for such things and you didn't create any to use with that application itself, it's probably not a good idea.
If it is asking for authentication from a known good source (twitter, fb, google apis for eg) then make sure you check which permissions it's asking for before authorizing it to use your account. In some cases, it's just as good as giving them your username and password - the only difference being generally you can remove the authentication if weird behaviour starts up.
Riots API
I am working on a pet project and need to overcome a major hurdle in an application. I have checked countless forums and articles and have only found bits and pieces of what I am looking for, so I hope a more direct approach will help me.
Here's the scenario:
1. The site is actually a game, which uses Javascript/JSON with DHTML on a page that has several IFRAMES - two of which are deeper inside the outside page AND of a separate domain.
There are NO security issues with what I am trying to do. All programming and access is limited to merely simplifying and automating normally access functions only. All authentication and private information is done prior to any access, and only the session information will ever be used, and only to facilitate game operations that the user knows will happen.
The idea is to use the webbrowser control to access the game and provide ordinary access, while the app hosting the browser gets the game session information and makes separate automated calls to the game servers. This has already been done via Firefox using Greasemonkey scripting, and it works well - except that Firefox has a horrible memory leak that eventually causes the whole operation to break down.
The problem I am running into is obvious. I am trying to access the iframe that is technically on a different domain, and the web browser DOM model won't let me in. I have seen enough articles to know there are several workarounds to XSS filter blocks but they are quite vague and vary depending on scenario.
So, I will outline exactly what I need in hopes that I can obtain an amicable solution...
I need to obtain the DOM of a nested IFRAME of a different domain. If need be I could live with just the source, but the DOM and the JS vars would be the most ideal. My strategy here is to use the session information and make HttpWebRequest calls parallel to the web browser in-game. That way I can automate some functions while still playing. It can be done - if I can get the session information and pass it the same way. It will all be done on the same client with the users permission and knowledge, so no security issues.
I would really like it if I could pass information BACK to that IFRAME. One of the major things this project is trying to do is make some visual changes to simplify the look and feel of the interface. It is all in HTML, so changes would simply be adding some in-line styling of JS code...
So anyways, what ideas and suggestions would work best? At this point I am open to all scenarios, but ideally something as simple as possible to get what I need. This is already a huge project :).
Thanks in advance!
If you are in control of all sites in question, you could use postMessage to communicate. Also there is easyXDM which provides a set of transports that also work in older browsers (and automatically picks the best one).
https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage
It's possible to bypass XSS checks and access iframes through IOleContainer, as described here. The sample is in C++, but it should not be a problem to do the same from C# with COM interop.
What is for sure, the more I read about WIF, the more I get confused about how to do things.
For something that was supposed to ease things, I can't imagine how it would be without. I guess there's too many scenarios and I have hard time to find the one that fits me.
For some (good for my point of view, but maybe bad) reasons, I want to avoid a official STS (ADFS or ACS) and then write my own to keep things simple!
What I'm looking for is being able to deal with Users (that I'll wrap from an AD identity), Groups of users (custom) and Roles that get users/groups assigned to (custom).
I want to decorate my client side methods with the ClaimsPrincipalPermissionAttribute (or a declarative equivalent) to check if the current user has the required role. I want to be able to use that from a Windows Client application or a WCF Service hosted on IIS/WAS (Net.tcp is my preferred choice of binding).
Some guidance will be greatly welcome as I'm tired to read on an on WIF materials without any improvement of how the solution could be shaped.
Thank you !
So first of all - there is no such thing as a simple STS. I hope you realize that an STS is criticial security infrastructure and probably should not be your first WIF project. If you want to have a look at an open source STS to get some ideas have a look here: http://thinktecture.github.com/Thinktecture.IdentityServer.v2/.
Next authZ happens on the server side (client side is usability). Simply roles checks are rather done with PrincipalPermission. ClaimsPrincipalPermission encourages you to separate service and security code - look up ClaimsAuthorizationManager for more information.
I recently launched my desktop application and it got cracked after a few days. I posted a question on stack overflow and people said that i cannot stop that. In the start of the software i cannot allow this to happen and i want a solution. So, following is what i am thinking.
Currently, I have desktop application that communicates with the web server to verify the user. Once the user is verified it saves the values in Registry. The hacker has bypassed the communication code and added fake values in registry and he can use my software now.
Now, i am planning to take some of my code from MAIN features of the software to a WEB SERVICE hosted somewhere else on a web server. Whenever the software needs to run that feature the software will give a call to the WEB SERVICE with the values in REGISTRY. I will verify those values and return the results. But if the values will not match my database then i will reject the call.
So, my questions is:
1- Do you think this solution is feasible ?
2- According to my thinking, it will make the software useless to the hacker. What do you think ?
3- Any flaws in this solution ?
You don't have to get cracked. Jeez, everybody thinks there's no solutions available to prevent piracy, but there are. Disclaimer: I work for a company (Wibu Systems) that prevents software piracy and provides license management solutions.
Here's the thing: this (like all security issues) is a highly specialized area of focus and the crackers are smarter at this than you are. They are already familiar with the different home-grown solutions people roll themselves and can crack those quickly.
Commercial solutions (ours is CodeMeter; in all fairness other companies make good solutions too like SafeNet and KeyLoc) rely on strong encryption with multiple layers of protection against key discovery. These companies have spent years developing, improving, and testing their solutions; it's unlikely you will be able to come close to the robustness and quality of such a solution on your own. I can almost guarantee you that any solution you create on your own will get cracked very quickly, unless your product is uninteresting to the crackers.
I'm not trying to create an ad here; I just want to set the record straight. Companies that traditionally got cracked constantly who switched to CodeMeter stopped getting cracked. Check out Propellerhead's Record product for a good example.
Is there any way to stop .NET Reflector working at a program?
For example: I am developing a program that has confidential data (like gMail address and password), and I don't want to someone can see them.
How can I do this?
There are various tools that promise this, via different techniques.
For example, many commercial obfuscators will, in addition to encrypting strings and obfuscating the source, also introduce things into the IL that allow the program to run but which break (most/all) of the current reverse engineering tools like .NET Reflector.
That being said, keeping this type of data within the application will never be safe. The best a tool can do is make it more difficult to get the information, but never make it impossible.
A tool which "masked" it and breaks obfuscation tools is still not perfect - with enough time and energy, somebody can get that information out of your program. If the information is available to the runtime, it's available to somebody with enough determination and drive to find it. As such, important, private information like passwords should not be kept in the executable.
Yes, search for '.NET obfuscator'. There are several tools available.
However, you should never embed your email username / password in the code. This is just wrong. Putting security aside, what would you do if you need to change your email password? Can you upgrade all the copies of your software out there?
Obfuscators tend to offer little in defense of data such as what you are keeping in your application. They are mainly meant to protect the code and logic from being reverse engineered, not literals. A better way would be to have your client application talk to a server-side app that feeds it the data it needs instead of having your client negotiating with the secure servers directly. With this way, you can set up secure method of encryption between your server and client application.