I'm developing a web page using asp .net and have another application which is published in my host. I want to access to the application just from my page and the application is not accessible from other IPs.
I used iframe, but iframe is connecting client directly to the application which is not what I want. How can I handle this?
I think without some wierd code, this is not possible since the IFrame is client side calls. This will make a hard time for you to bypass.
A little side question is, why dont you want people to access you page directly on the domain / ip, when showing it in the iframe will still let people access the page?
Related
Scenario:
ASP.NET 5 / Razor Pages / C#
We have one main site, with very good security. In the background, all passwords are encrypted. Also, a log is made of all logon usernames, from which IP addresses, at whatever time accessed.
We have a second site that is hosted within the main site visually on the front end via iframes mostly, but not on the server. They won't live together in the same web app.
Problem:
I need to ensure that the secondary site access is secure, whilst relying on the fact that the user already logged on successfully via the main website. I don't want the user to need to logon twice to two systems, rather I want the single logon to fluidly allow access to the secondary site.
I have a method I am using now. It works, but I really want to delve in and see if I can improve this given I'm not heavy on experience in terms of website security. I'm sure there is a better way.
Options?
From a security point of view, using iframes, the two site are independent.
So you need to guarantee that the security process is issued on both sides.
You have several possibilities, but the best, I think, is to revalidate the user in the "iframed" website.
You can use a token, generated from the main website and stored in a backend DB, and pass it to the iframe URL.
The endpoint of the iframe has to read the token, call a backend API to validate it and allow the access.
The main problem you have is to refresh the token after a reasonable time, in order to ensure the validity during the use of the "iframed" website.
Problem:
Asp.net WebForm application is loosing its session data (loosing ASP.NET_SessionId cookie) between any Requests, when having web app framed(via Iframe) inside another app hosted in another domain.
Our Setup:
We have 2 applications - each hosted in its own domain(not sub domains);
1st being an asp.net webform (.Net 4.6.1) apps lets say A,
Another application(Not on .Net), lets say B.
A (webform) is being framed/opened inside iframe from B(Not .Net).
Problem in Detail
When first time A opens in Bootstrap popup(using iframe) inside B, it shows an aspx page.
From there if user does any operation with in iframe, which if makes another request to A itself with in iframe (postback or redirect),
then previous session (internally ASP.NET_SessionId session cookie) is getting lost and new session/cookie is getting re-created.
This breaks application logic/behaviors as we need active session for all requests of A.
Solutions Tried
We are going to follow one of below (either via code or configuration options available in 4.7.2), and have tried one on POC level and seems fixing original losing session issue.
ASP.NET webform loses session when getting posted data from another domain
ASP.NET_SessionId cookie value is alway Lax in the SameSite
Queries I have
Will using option of setting samesite as none, and cookie to be secured (if app A is accessed via https always) cause any additional security risk? - If both A and B are owned by us and in our domains.
If yes, what is risk involved? can it be recommended to used in production box for setup we have?
I understand even with above option, we will still loose session data when our app B is opened in chrome's incognito window and B then tries to open A in iframe?
Is it correct?
If yes, what are solutions/alternatives or even workarounds(only as last resort)?
I found one, but that recommends to use cookieless session, which we cant as our authentication is based on cookies.
Let me know please if need any additional details. Thank you.
I am developing an ASP.NET application. But i would like to hide the URL so user don't know on which page he or she standing. Is their any solution?
Use Server.Transfer . It doesn't change the URL.
Server.Transfer happens without the browser knowing anything, the browser request a page, but the server returns the content of another.
Server.Transfer() should be used when:
we don't need to show the real URL where we redirected the request
in the users Web Browser
we want to transfer current page request to another .aspx page on the
same server
we want to preserve server resources and avoid the unnecessary
roundtrips to the server
we want to preserve Query String and Form Variables (optionally)
There is no solution unless you can force the user to browse only from a restricted environment in which you can control what software is installed or run. Even if you force the user to use a specific browser, they could use a tool like Fiddler to see what URLs they are going to.
I have a program that opens a web browser control and just displays a web page from our server. They can't navigate around or anything.
The users are not allowed to know the credentials required to login, so after some googling on how to log into a server I found this:
http://user_name:password#URL
This is 'hard coded' into the web browsers code. -It works fine.
HOWEVER: Some smart ass managed to grab the credentials by using WireShark which tracks all the packets sent from your machine.
Is there a way I can encrypt this so the users cannot find out?
I've tried other things like using POST but with the way the page was setup, it was proving extremely difficult to get working. -(Its an SSRS Report Manager webpage)
I forgot to include a link to this question: How to encrypt/decrypt the url in C#
^I cannot use this answer as I myself am not allowed to change any of the server setup!
Sorry if this is an awful question, I've tried searching around for the past few days but can't find anything that works.
Perhaps you could work around your issue with a layer of indirection - for example, you could create a simple MVC website that doesn't require any authentication (or indeed, requires some authentication that you fully control) and it is this site that actually makes the request to the SSRS page.
That way you can have full control over how you send authentication, and you need never worry about someone ever getting access to the actual SSRS system. Now if your solution requires the webpage to be interactive then I'm not sure this will work for you, but if it's just a static report, it might be the way to go.
i.e. your flow from the app would be
User logs into your app (or use Windows credentials, etc)
User clicks to request the SSRS page
Your app makes an HTTP request to your MVC application
Your MVC application makes the "real" HTTP request to SSRS (eg via HttpClient, etc) and dumps the result back to the caller (for example,it could write the SSRS response via #HTML.Raw in an MVC View) The credentials for SSRS will therefore never be sent by your app, so you don't need to worry about that problem any more...
Just a thought.
Incidentally, you could take a look here for the various options that SSRS allows for authentication; you may find some method that suits (for e.g Custom authentication) - I know you mentioned you can't change anything on the server so I'm just including it for posterity.
When you created a wcf service, hosted it in IIS and then opened service page in browser you will see a default wcf help page. This page says 'You've created a service'.
What do u do with page? Do u hide it? Or replace it with your own?
Thanks
I'm not even sure you CAN hide them; you have to be able to access the URL in order to invoke the service properly, and the .svc markups don't allow ASP content to be displayed instead of the basic metadata pages. I think the only way you could do it is with a service in front of IIS, evaluating requests and redirecting "naked" service requests to a catcher page.
Being able to browse to the page is a useful diagnostic and DIY tool. If you can see the page from the browser of the computer with the client software, then you should be able to connect to that service using the client software. So, unless you can think of a security or aesthetic reason why the page cannot be exposed in your production site, I'd just leave it be.