Is there a way to disable the X-Frame-Options header in the WSO2IS responses? We need to integrate one application within another with the use of an iframe. Both applications are using WSO2IS for authentication though the one in the iframe will redirect to authenticate with OpenID Connect but it should return back immediately since the user has been authenticated by the parent application. Now as it is, I get X-Frame-Options: DENY headers and since the WSO2IS is located in a different domain than the application. Any suggestions?
After a little thought and since there is no answer yet, I believe I can answer my own question. Since it seems that every SSO system out there will serve the X-Frame-Options header with a DENY value, the only solution would be to pass the OpenID Connect Code from the parent application to the iframe child application as a parameter. In that way, the redirection step is not needed and thus the nested/child/whatever application can make the requests for the token and user info. I don't know if this is a nice way to do it, but it seems the only way that will work with WSO2IS or any other OpenID Connect based SSO system.
Related
Let me explain in detail
I've 2 servers hosted and one of them for Back-end and other is for Front-end.
Back-end server : 127.0.0.1:8000 (just for explaining)
Front-end server : 127.1.1.1:9000
User requests UI from Front-end server and if he wants to create an account on my website he needs to send POST request to 127.0.0.1:8000/create-account/ and this works fine
but if I open console of other website or make use of Postman, I'm able to achieve the same results.
So I want to prevent this thing and only allow anyone to create account from my website only.
Methods which I've tried
I've used windows.location() and sent it to server and then verify if domain name matches. But in this method everyone can just pass it simply via fetch()
I've used allow only IP address, But if I push my website in production Other visitors get 403 error.
I develop back-end with help of Django and rustlang
It isn't possible. You can make it hard for entry-level programmers to reverse-engineer your solution, but there isn't any way to prevent access to your API if you are going to allow access to it from some public UI.
IP address-based restriction will not work here because your backend will receive the IP of the user. In this case, you will be blocking access to users, not to any UI. Even the host header verification doesn't work here as anyone can use a proxy server, i.e. NGINX, to override the headers and can fake the request to originate from an intended website.
IP address-based authorization can work only if API calls originate from a server and your API server receives the same IP address for each API call. But for your use case, it isn't applicable.
The older techniques like CSRF are useless too as anyone can easily retrieve the token and can send it. In short, if you make something public, it can be reverse-engineered. If you are accepting public registrations, there shouldn't be anything to worry about the registration source. You should think about solutions like email verification etc. to reduce the spam if that's the concern.
You could have your frontend solve a recaptcha and send the solution to the backend. Verify the solution before accepting the request. It is still possible to bypass although a bit harder.
I'm experiencing the same issue as the one mentioned here, for which there was no conclusive answer: Asp.Net Owin authorized request works in Incognito mode but not "normal" Chrome
I am unable to comment on that question as I do not have the reputation to allow but was going to ask whether it is something to do with the fact that my project includes both Web Forms and Web API and there is a conflict going on with the authorization cookie.
Has anyone else come across this issue?
Thanks
For the benefit of anyone else with the same issue:
It was indeed due to forms authentication being enabled at the same time as OWIN bearer tokens.
If you are logged in via forms authentication, then try to call a web api end-point in the same browser, it uses the cookie information which gets recognized by Web Api authorization.
In incognito, there is no such cookie so behaves as expected.
I'm using Django Rest Framework and Token Authentication. Everything works great so far.
http://www.django-rest-framework.org/api-guide/authentication#tokenauthentication
But I'm realizing that anyone could create a third party app that hooks into my API. There'd be no way for me to detect it or stop it.
Am I missing something? I followed the directions, and I:
Send "username=blah&password=blah" to https://example.com/api/auth/, and receive a Token in return. Anyone could do this from a third party app.
That token is passed in the authentication header to retrieve data from the API. Anyone could do this if they have their user token.
Even if a user knows their own Token, I only want them to be able to access the API through the official native app.
1. How do I secure my API (using Token authentication) and make sure that only MY apps can connect to it?
2. Could I include some kind of secret key in a header? I'm using HTTPS in production, are headers as well as form data (username/password) interceptable/readable? (By the person running the app).
Still learning, thank you.
Perhaps I don't understand you question fully, but:
yes, everyone with a username and a password in your application can create tokens, if you added obtain_auth_token to your urlconfig (what you don't have to).
So you can:
only give your apps username and password
or deactivate the obtain_auth_token view and create the tokens in the admin or manually.
To answer your HTTPS question:
HTTPS encryption is between the client and the server and lies between TCP and HTTP. So everyone in between (a man in the middle) can't see any headers, data, or even the path. When using SNI the hostname (Host header) is visible, but nothing else.
Hope this helps a little.
I'm very novice when it comes to web applications and ASP.
Recently, I've been experimenting with the Microsoft Sync Toolkit to synchronize databases over a OData web service.
The obvious question here is: Once the service is set up and published - so it is open for anyone knowing the URL - how to prevent unauthorized users from accessing this service.
Please note: Basic authentication of forms authentication - as far my little web development knowledge reaches - doesn't seem to be appropriate for this task, as it's not a web page that the client is trying to reach - where the page can display / or re-direct a logon request - it's a service that we are accessing here.
To make things more difficult, for the client-side syncing I'm using a 3rd party library/sync-provider that only accepts a URL for the service. So, there's no way (I think) I can experiment with incorporating login credentials inside a request header etc.
I assume the best bet would be embedding the login credentials inside the URL and use that for the 3rd party library.
Can somebody please direct me how to to set up such thing on the server? I would prefer to have somehow somewhere in the server-side code a place where I can check for the credentials and based upon it to proceed or abort (return 401) the service request.
I could not find any place where to hook such code into the sync service. Although somebody in MSDN suggested to handle the _OnBeginSyncRequest event, there is no way to access the web-request header from within that method.
Is there by-any-chance a global object accessible from everywhere from which I can access the request header? Could anyone please help with this?
And last, I would prefer a plain User / Password string pair. It should not necessarily (or rather not) have anything to do with windows or directory accounts. I would prefer in my code to simple check against plain strings, such if(userStr == "Authenticated user" && passwordStr == "Correct Password").
if you are using SOAP web service, you can use WS-Security usernametoken which adds your user name and password to the request header, otherwise you can add username and password as parameters in your webservice and then simply validate it on the server side. i.e.
instead of
bool SyncData(datatable)
it becomes
bool SyncData(datatable, username, password)
note for web service you will authenticate per call, if you want to do it per session, you need first login with username password, retrieves a token than on each subsequent call your service with the token.
You would also use SSL to secure the channel so username and password aren't transmitted as plain text.
This is a similar situation to the one raised in this question:
Javascript Calling a Rest API with App Name and App Password - How Can i Secure it
Here is the architecture overview:
The site is Html5/jquerymobile
It contacts what I call a "Wrapper" service.... This is a REST API I wrote in C#, to contact another 3rd party REST API. I do this because there are credentials in the Header and the API uses Basic Authentication. Credentials are therefore not publicized as they are only known server-side.
My "Wrapper" service does not currently implement any additional security. It is currently accessible from anywhere. The easiest and quickest way to lock it down is to restrict by IP, so no other IP anywhere except the server can actually contact my wrapper service.
The questions:
Is the locking by IP the only way to ensure that the API won't get hammered if it was otherwise accessible from anywhere?
If I convert this using Phonegap (which I have... and deployed successfully on Android), obviously the native app won't work if the web service is restricted.
Is there a way around this so I can allow traffic only from the mobile app, and not from any other source? I'm thinking along the lines of MD5 hash or something that could be sent to the wrapper API.. but unfortunately I'm thinking that info can easily be "sniffed".
Is my only viable option here to release the app as a web app, forcing browser use, thereby removing any concerns about allowing my web service to be hammered??
I believe the answer to this is a combination of a user token and encrypting the message through SSL.
The server can issue a valid user a token so we can identify him in future requests.
Encrypting it via SSL will ensure that this token cannot be sniffed.
https://security.stackexchange.com/questions/12531/ssl-with-get-and-post