I will try and keep this as short as possible, although I may be leaving some things out, due to inexperience and/or lack of knowledge.
I have successfully been able to redirect from Website A to Website B, much like what was illustrated in the link C# - HttpWebResponse redirect to external URL (Thank You to everyone involved, this was very helpful)
The only problem is, that in Website B, after the redirection seems to have been successful, the system seems to ignore what happened , and redirect again back to it's Default home controller index Get Action result, and continues to Log in as if the Redirection never took place. I have removed everything that may cause this, in my opinion, like Attributes to check authentication etc.
Any help in this regard will be much appreciated.
According to your reference link( https://stackoverflow.com/questions/27503986/c-sharp-httpwebresponse-redirect-to-external-url), they try to create a single-sign-on system. Because they have 2 websites. The question of this link that how can they solve this problem with HtppWebRequest class. This is not possible ofcourse.
If you look at the answer section that I added on image, Author offer to use cookie sharing.
What is the correct solution to share authanctication info between different web site?
You should search about on Single Sing On Authantication methods.
Here is a few clue
OAuth(Google, Facebook)
SAML Protocol
JWt
may Jwt a bit hard way ;)
Related
We have a homebrewed advertising system on our website. Part of this includes code that when an ad is clicked, we first go to a intermediary page that records the click data, which then redirects them along to the desired advertiser's website.
Unfortunately, our current solution requires that a URL parameter be passed to the intermediary page that is the destination URL. Some savvy advertisers have discovered that they can use this for their own nefarious purposes and "launder" their traffic through our site. In other words, on their site, they have a link along the lines of www.oursite.com/redirect?URL=www.theirtargetsite.com, making it seem like that traffic is coming from our site.
I'm working on a solution that will only redirect to a whitelist of URLs, but my first problem is more just knowing what this is called. Finding alternative and probably better solutions is difficult when I don't even know what to call it. With so much spoofing, laundering, and hijacking going on, it's hard to find help for the right topic.
What is it called when website A redirects to website C through website B without the permission of B?
The word you're looking for is open redirect. The MITRE article on this class of vulnerability has some examples of ways that this can be mitigated, e.g:
Whitelist the URLs that you will redirect to
Displaying a warning page before redirecting (probably not viable in your situation)
Use numbers to identify the URLs to redirect to (i.e, look them up in a table) instead of putting the target in a query parameter
Use a HMAC construction to "sign" URLs to redirect to, and reject redirects that don't have a valid signature
I just want to know if there is a naming standard on REDIRECT URIS for :
Twitter, LinkedIn, Microsoft, Facebook and Google when using OAuth 2.0?
Because, if I write my domain like that : http://domain.com/account/external-signin.aspx every external login stop working except Twitter and Facebook. The name account/external-signin.aspx is the real URL I'm working with and that I'm supposed to give to every external login.
So, Microsoft give this error:
We're unable to complete your request
Microsoft account is experiencing technical problems. Please try again later.
LinkedIn:
Invalid redirect_uri. This value must match a URL registered with the API Key.
And Google
400. That’s an error. Error: redirect_uri_mismatch
If I remove the page extension .aspx it seems to work although I deliberately write a wrong url like http://domain.com/sign-google, http://domain.com/sign-microsoft etc...
I'm working with MVC5 and C#.
I think I missed a few things ...
Thanks for your help
So finally, here is the correct answer:
It's not you that choose the redirect URL. You must write your domain.com/signin-{suppliername} in your app management.
Example:
Microsoft : https://domain.com/signin-microsoft
LinkedIn : https://domain.com/signin-linkedin
Google : https://domain.com/signin-google
Facebook and Twitter can work with your own redirect URL. Once successfully registered, the effect is immediate. Hope this can help somebody.
Karine
This error is denoting that you're having a miss match with the URL you're returning, and the return URL registered at the API Server. When you register your application, at the server, (for Google: https://code.google.com/apis/console) you have to make sure that the URLs being used would be matching.
After this, you will not get this error, I think on the server you've set this property to, http://domain.com/account/external-signin (without aspx; as you've said that this works without the extension but not with it). So try to change it on the server too.
For Linkedin append your url with "signin-linkedin".e.g. if your url is http://localhost:{portnumber}, make sure its is register in linked in as "http://localhost:{portnumber}/signin-linkedin" and this will do the trick.
Happy Codding :)
I am using the following code to redirect to the referrer in my controller:
return Redirect(this.HttpContext.Request.UrlReferrer.AbsolutePath);
During a scan with an application security tool it pointed out that the above code enables phishing attacks.
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link to generate a redirect. This enables phishing attacks.
Is there any way to safely redirected to the referrer?
This sounds like a general-purpose error, that is probably harmless in your case. The app sec tool doesn't realize that you're sending people back to the exact page they came from, but rather it sees the potential for you to do something like:
return Redirect(
is_trusted_site( this.HttpContext.Request.UrlReferrer.AbsolutePath )
? sensitiveURL
: otherURL
);
If the redirected URL changed depending on the content of the UrlReferrer, then you could fall prey to referrer spoofing.
Just the same, if you want to fix the "error", you can perhaps use JavaScript's history.back().
I don't see any problems with this, given that what you actually want, is to redirect to whoever puts a link to your site on the whole Internet. You have no control over how the "referrer" ends up in the HTTP header. It might be legit, it might be forged. If this is OK with you, I see no problems.
Be aware that someone CAN use your site to redirect to anything, and that opens up for possible attacks. I.e., send an email that acutally links to your site, but in a query parameter specifies a phishing site.
What are you planning to use this for?
I have to implement a single signon kind of solution on my website. Let's say my website is www.myweb.com and I want to allow the users to use this site who only come from a site www.sourceweb.com.
I thought URL Referrer would do but in IE may comes null.
See here
Please suggest me some alternate solution.
Thanks,
Gaurav
If you have access to www.sourceweb.com and can modify the source then a possible solution would be:
Create a webservice on www.myweb.com.
Create a link on www.sourceweb.com
When the link is clicked call the webservice to retrieve a unique id.
Redirect the user to www.myweb.com and provide the unique id in the querystring.
On www.myweb.com confirm that the unique id is valid and remove it/mark it as used.
There are many ways to skin a cat, one way in your case would be to set a cookie on the 2nd site, using a pixel gif (1x1 pixel small picture) embedded on a page of the main site. The 2nd site then can later allow access only when the cookie is already set.
To make this secure, you have to add a token to the pixel gif URL, containing a timestamp and signed using a HMAC or something similar establishing a shared secret with the other site. Then you only set the cookie when the timestamp is recent (less than a minute ago) and properly signed.
URL_REFERER is your best bet.
Keep in mind that like most HTTP headers, it is easy to forge and does not have to be provided.
The very short answer. Don't implement this yourself.
Security solutions should not be implemented but bought. The only exception being if you actually develops security solutions for other to buy of course.
Choose one of many available SSO solutions and go with that. We use Microsofts ADFS, though not perfect it gets the job done for us with very little maintance and the only real hazle is for our applications hosted on non-windows platforms like AIX.
There so many chance of screwing things up when you try to implement your own security solutions. If you disagree than just remember than anual contests are held to break the security systems of companies such as Apple,Microsoft,Mozilla and Goggle and most of the years some one takes home the price for breaking each of them.
We've now got plenty of sites which all use a log4net base error loging framework and we receive error from site from anywhere it append. We've notice that some of them catch error because of "Bot" like google, bing, yahoo, etc. But there's a things we've not sure about how to resolve. I've two questions about it :
Is "Java/1.6.0_24" a Bot? Because the user-agent of my question #2 is about this.
The "Java/1.6.0_24" still calling subfolder on our site that just do not exists! Like, if we have a page called "Page1.aspx", instead of calling "~/Page1.aspx", he calls it "~/minisite/Page1.aspx". How can I tell him he's wrong? Is there a way to do it?
Thanks you
It's most likely a bot but it could as well be some kind of browser based on Java that sends that user-agent string - you can't trust it 100% but it can give you an estimate idea of what the connecting entity is. Depending on the kind of bot it might as well just ignore your robots.txt so I'd just impement some handling stuff somewhere.
Did those folders ever exist? If so, you could use HTTP's permanent redirect (code 301) to tell him to no longer look there - however that doesn't guarantee it will do so.