I am working on one fortify issue which says that any area of the website or web application that contains sensitive information or access to privileged functionality such as remote site administration requires authentication before allowing access. The URL ~FullURL~ has failed this policy.
Please let me know in case anyone face similar issue
Regards
Related
I'm working on a project using the YouTube Data API. The Python script I'm running uses a client secrets JSON file, which I presume is for verifying the account owner. If I am having issues with it and need assistance, are there any security concerns with sharing this publicly? Is it even alright if it's held privately in a private github repository?
If you check the Google Developer TOS which you agreed to when you created your account on Google developer console
It is against the TOS for you to share this file with anyone. This is secret and only intended for the developer or team of developers who created it. This pertains to the entire client secret json file you download from Google developer console or google cloud console.
Again DO not share your google secret file. No matter what the accepted answer stays about how problematic it may or may not, nor does it matter what type of client it is. Sharing the client secret file would be volatilizing the TOS you agreed to.
My corrections for another answer on this thread here
The answer in question has some statements that i strongly disagree with and feel may cause confusion to developers. Let me start by saying I am not an employee of Google, my comments are my own and from my experience with working googles oauth / identity server server for eight+ years and contact with google identity team. I am concerned that some of the information in the answer above may confuse some developers. Rather than just saying dont share them the other question tries incorrectly IMO to explain why it wouldn't be so bad to share them. I will explain why you should never share them beyond the fact that its against googles TOS.
The security implications depend on the type of client secret. You can tell the difference by whether the key in the JSON file is installed or web.
The type of client has no effect upon I how great the security risk would be. If we ignore the definition of what a constitutes a security risk completely and just say that any chance anyone could get access to a users account or authenticate a user on behalf of the project, would constitute to big of a security risk then there is no difference.
Using the following command I could authenticate myself all i need is the credentials file for your project
https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
This would only work 100% of the time for an installed application. Why is this bad if i am just authenticating my own user. I could then use my evil powers to send so many requests against the API that the target google developer project would be locked down by Google for spamming.
If i have stolen another users login and password i can login to them from your Google developer project and i have access to their data and Google thinks its you hacking them.
This is a little harder with a web application due to the Redirect URI, However a lot of developers include add localhost as a redirect uri when in development and forget to take it out (Please never leave localhost as a redirect uri when you are in proudcution) . So in the event you have left redirect URI as a valid redirect URI in a web browser client then I can do the exact same thing.
Remember I am now able to authenticate users based upon your project to access mostly my own data. However if you have also set up access to client data for example via google drive I may be able to access that as well. (Note: Im not Sure on this one i havent actually tried.)
If i have manged though man in the middle attack or some other means to get a users refresh token, and I have the client secret file I can now access users data because I can create new access tokens with my refresh token for as long as i want. This is probably a bit harder to achieve.
Web application secrets
If the client secret is of the web type, then yes: you should absolutely not post it, and invalidate it if it gets exposed. This would allow a malicious entity to impersonate your backend and perform actions on your users' accounts on your behalf.
As stated above this will only be the case if the developer in question has left the redirect uri open for localhost or the person who now has your client secret file also has access to your web server. One very important fact is that if you have left localhost open i can then put up my own website using your credentials and set it up so it look exactly like your website. Users then think they are logging into Your super awesome app when in fact they are logging into Hacker Super awesome app giving them access to the users data. Again google thinks its you hacking them.
Installed application secrets
If the client secret is an installed-type secret, then it's less problematic to share privately, as it doesn't grant the sorts of abilities a web application secret does, such as the ability to authenticate as users who grant your application permission to access their data. As the documentation notes, "in this context, the client secret is obviously not treated as a secret."
This is completely false Installed applications give the exact same permissions as web applications there is no difference with-regard to Oauth2 access an access token is an access token no matter if it was created for an installed application or a web application.
As stated above security risk with giving out access to your installed application this is actually worse. As there are no redirect uris with installed applications. Anyone that has access to your client secret file could authenticate users who assume they are you because they are being shown your consent screen. Not only is your Google developer project being hjacked but your reputation to your users who think that they are authenticating to Super awesome app and in fact they are not granting the person who has stolen your credentials access to their data.
I would like to add one last thing. If you give another person your project credentials. The client secret json file. You are giving them access to make calls on your behalf. If you have bulling set up lets say against google maps api. You will be charged for the calls they make.
I hope this helps to clear up some of the confusion related to the accepted anwser.
Yes, this is a problem. It's called a "client secret" for a reason. If it does become exposed, you should take steps to invalidate it and get a new one so that someone doesn't try to impersonate you.
Short answer: the security implications depend on the type of secret, but you should not share it publicly for other reasons, including the Terms of Service, which state that:
You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.
The security implications depend on the type of client secret. You can tell the difference by whether the key in the JSON file is installed or web.
Web application secrets
If the client secret is of the web type, then yes: you should absolutely not post it, and invalidate it if it gets exposed. This would allow a malicious entity to impersonate your backend and perform actions on your users' accounts on your behalf.
Installed application secrets
If the client secret is an installed-type secret, then it's less problematic to share privately, as it doesn't grant the sorts of abilities a web application secret does, such as the ability to authenticate as users who grant your application permission to access their data. As the documentation notes, "in this context, the client secret is obviously not treated as a secret."
You still should not post it publicly on GitHub, a Stack Overflow question, or other public places, as posting it publicly increases the probability of someone copying your code in its entirety or otherwise using your client secret in their own project, which might cause problems and likely would run afoul of the Terms of Service. People trying to reproduce your issue could pretty easily generate credentials to drop into your code—credentials are a reasonable thing to leave out of a question.
We have a bunch of websites under re-built and few mobile apps under development. We are looking for a Identity Manager / Server that can be used for authentication and authorisation of the users logging into those portals and apps. I did some a brief research but could't find the answer to my questions below:
Does't MIM support OAuth2 / OpenId Connect based authentication protocol?
Can we create user profile and add users claims in it?
Does it have APIs that portals can call to add users into the user storage?
Does it provide API endpoints for change password and forgot password to add self serve password recovery feature on the portals?
I am a developer and have little knowledge about active directory and identity management area.
I was in the same boat you are in, and was trying to decide between MIM and Red Hat Keycloak. I ended up going with Keycloak, it is powerful yet easy to setup, configure, and manage, whereas MIM is a pain in the neck to setup.
It sounds like you are looking for a single signon or federation solution, if that's the case MIM won't be able to help you. MIM is designed to synchronise user accounts from an authoritative source and maintain them in other connected systems (typically HR to AD).
The equivalent product to Keycloak in the Microsoft space would be ADFS (Active Directory Federation Services) or Azure AD.
I need to create User Management Service which will be central point to authorize AD users for multiple applications. Applications can be both intranet or Internet, internal or external.
What I figured out it will be something like Identity Server. But due to some requirements we doesn't want Identity server but custom STS (Security Token Service).
- We need to take input from 3rd parties credentials
- validate in our Active Directory
- generate & send SAML token to authenticated users.
I have looked into :
https://katanaproject.codeplex.com
http://www.c-sharpcorner.com/UploadFile/scottlysle/windows-identity-foundation-and-single-sign-on-sso/
http://garymcallisteronline.blogspot.in/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
https://msdn.microsoft.com/en-us/library/ms972971.aspx#singlesignon_topic9
https://coding.abel.nu/2014/08/kentor-authservices-saml2-owin-middleware-released/
But I am still confused how 3rd party will understand that SAML or need what to interpret that shared identity info.
3rd party app can be on any language other than .Net too
they don't need to make change into their code/implementation.
Please suggest.
This is conceptual/architectural question so please don't advise to add code & then to offer help.
We have a website deployed with Impersonate=true.
A connection string is defined as this:
Integrated Security=SSPI;Persist Security Info=false;Initial
Catalog=MyDatabase;Data Source=MyServer;
I assume Persist Security Info is redundant as that only applies to SQL authentication? We need to use integrated security as can't have passwords in the config file due to corporate security policies.
The website runs under a service account. The service account has permissions to access the database, but other accounts do not have access (security policy).
The problem we're facing is the user account is being passed to the database and being rejected, due to Impersonate=true.
We're required to have Impersonate=true for a Single Sign-On component to work.
Is this a catch 22 or is there a solution?
I hope I've written this clearly enough!
As per http://msdn.microsoft.com/en-us/library/134ec8tc(v=vs.80).aspx
"Impersonation is independent of the authentication mode configured using the authentication configuration element. The authentication element is used to determine the User property of the current HttpContext. Impersonation is used to determine the WindowsIdentity of the ASP.NET application'" Accordingly, you do not need to enable impersonation to be able to authenticate users. Note however that your application will have to handle authorization. A ready framework to implement authorization is NetSQLAzman, see http://netsqlazman.codeplex.com/
I have developed an MVC intranet application which I have successfully deployed to IIS.
I have enabled Windows Authentication and denied access to anonymous users, however, only some accounts on the domain are able to gain access to the application.
I have checked these accounts and there is nothing special about them that I can see.
The first check for security is Domain Users which everyone is a member of.
All other users are prompted to login but it does not recognize their credentials.
I get a 401.1 - Unauthorized Error
Not sure what else to try. Any suggestions would be appreciated.
Solution : Folder permission on my wwwroot - Domain Users did not have read access.
=================================================================================
Check that kernel mode authentication is on:
Site>Authentication>Windows Authentication>Advanced Settings
Check authorization rules are not blocking users:
Site>Authorization Rules
I would test (allow all users) first, does that allow users through?