Is there a security risk if an application called page.ashx called internal only page.ashx, can a hacker conclude that another page is called.
I don't want anyone to access this page. it looks stupid I know, but it is a part of more complex problem.
thanks
"I don't want anyone to access this page."
To archive that you need to check if your user is authenticated one inside this page, or this page is in the directory that this roles of authenticated users can see.
The redirects can been read - so if you have some other page that redirect to the one you say, this is visible.
The server transfer however can not bee read and its internal, but I do not know if this can help your case.
By default, an ashx handler can be accessed just the same as an aspx page.
It is unclear what you mean by "internal". If the call is made at server side you can hide the file by removing permissions on the IIS. However, that may indicate you don't need a handler at all, and can probably call the function directly.
If the client need to access it (if it's returning a script or an image, for example), you cannot prevent direct access to it.
If you're looking for security light, you can obfuscate the URL with a hard to guess file or folder name and then use server transfer as Aristos suggested.
If you're looking for fancier security, then implement a web service instead of an ashx that requires authentications from the calling code with application credentials (something the application has that the user doesn't have so that the user can't call the service directly).
Related
I have an ASP.NET site which requires a login to get access to the rest of the site. Login information is stored in database and accessed through a service.
The business have asked to be able to login from an external site. I added a Generic Handler (.ashx) to my project which takes username & password input, verifies the credentials, and then if they are valid stores the credentials in the session using IRequiredSessionState interface. It then gives a URL of the entry point to the application to the client.
The client (a plain old HTML page using jquery to .post()) then takes the response and redirects to this URL.
Well, this seems to work great and exactly what I needed. I figured that I could avoid having to generate a token and pass it around in the querystring by doing this, since the handler and site both share the same session. But the problem now is when I tried a test by putting the Login HTML page on a co-workers computer (eg external to hosting in my application) - it doesn't work. The session is added correctly in the ASHX handler, but in the Page_Load of the entry point, that session value is gone..
Is it possible to do what I am doing? Why is session forgot immediately like this? I would think it would be the same as logging in from the log-in page and redirecting from there (it's the same application & the same session..)
Thanks!
I have a system which will update some UI details regarding user notification every X seconds (just like StackOverflow's notification, gmail inbox and so on).
I am planing to have a webservice that will check for new notifications and have it called every X seconds. The fact is: I do not want to make it public for everyone, I want to make it accessible only to my system, so it is the only one able to consume it.
Is there any way to do that? Using a WebService is not required, if you have other approach I would like to hear it.
My system is built using ASP.NET 4.0 and Microsoft's MVC framework. Could I call an action to do that?
My question is similar to this: How do I secure ASP.NET web service to only allow relative path calling?
But as far as I understood the answer, he proposed that the webservice could be turned into an ordinary class method inside the system that is not accessible from outside. This does not work for me because I want to access it from the client side.
Thanks,
Oscar
ps: changing infrastructure configs (ex: hosting it in an internal server) would be hard to do...
EDIT: what I want to achieve with this webservice is to update the notifications number. This should be done without refreshing the page, for this reason I thought about verifying with the server if there are any notifications and, if there are, update the UI.
Edit2: I could transform this webmethod in an ordinary method inside my system, that would be no problem. The question would then change to How do I wire the client to this method? Maybe calling an action using javascript and then inside this action calling the method?
Deploy this WebService on a different web site and then configure this site to be accessible only from IP : 127.0.0.1. Also checkout this blog post - you could install the IP Security and then:
Lastly, to create the restrictions, open up the IIS Manager and select
the website that you want to restrict. Open the IP Address and Domain
Restrictions module, and then in the actions panel (on the right side)
choose Edit Feature Settings.... To only allow local browsing, you
should deny by default. Choose Deny from the dropdown, and hit OK.
Then add your exceptions -- the IP's or ranges that you want to allow
access to. To do that, choose Add Allow Entry... from the action
panel, and add all the exceptions you need.
Now, only applications running on the same web server can access this web service.
If I give the Asp.Net user account (Network Service for Win 2003) modify rights to the root folder of my public website can a user send a request to the server to somehow modify the .aspx files of my website? What are the risks of doing this?
Short answer: Don't do it
Long answer: Still don't, but here is one scenario followed through that might make you think twice (there are prob many many more):
If you have an file-upload control anywhere on your site, say for image uploads, and an attacker manages to compromise your security (don't forget this does not necessarily mean breaking your site - they might just hijack someone's session or manage to guess/steal password) they can upload a malicious script (.aspx page). The site has "modify" permissions so it can write the file to disk.
I see you tagged the question with .net, so imagine they upload an .aspx page with some <script runat="server">...</script> that reads the contents of the web.config file and displays them.
Did you put any database connection strings with passwords in clear text in your web.config file? Cos' if you did, imagine their next step is to upload a new .aspx file that connects to those databases... they can then read your databases, delete data, change data... They probably don't really need the username/password because they can just use your named connection strings, but that information could be useful for another attack that I haven't thought of here.
I think you see where this scenario goes...
Is it safe to give the Asp.Net user account modify permissions to the root of the website?
100% definitely NOT.
can a user send a request to the server to somehow modify the .aspx files of my website?
Only if you build a page that does this in response to the request. Otherwise, no, not in one request.
What they can do is things like submit forms with way more characters in each field than your page was built to handle and attempt to create a buffer overflow they can exploit. But that happens over multiple requests. Or they can create an interactive http session and look for vulnerabilities to hijack your process that way.
Don't do it, it's dangerous. If you do, and if a malicious user finds a security hole (either in your code or in IIS), they will be able to modify files executed on the server and therefore execute malicious code.
If you need to write/modify files on the web server, you better give the aspnet user permissions to modify a separate folder, which will not have "execute" permissions under IIS (and perhaps even invisible to IIS altogether).
More info (regarding minimal required permissions, and therefore recommended maximal permissions): http://support.microsoft.com/kb/815153
I've got SL application where i should implement file managment subsystem. I've got hierarchical structure of files\folders(just description). Also each file\folder has its own permissions to users\groups. I would like implement that one user who has permission to download file couldn't give it to another user, who hasn't this permission. So if user has download permission he get link www.site.com/file.rar and download it. But he could give this link to another person without permission. What alogorithm is more appropriate in this case? Any help would be appreciated.
The web server needs to be in charge and provide authentication and authorization for any file requests. It's not specific to Silverlight as this is a general problem.
Your web server must validate each file download request against the currently logged in user (which, if you were using ASP.NET, could be using one of the authentication methods such as Forms Auth, or Windows Auth for example). You might have an HTTP Handler for example that does this validation and allows the download (and provides the download file's bytes). Here's an older example, but looks like it's still applicable for ASP.NET for example.
Or, you could provide a securely generated, expiring (maybe one time use?), token in place of a file name, which maps to a preauthorized file request, and again serves up the file on demand. This one is more difficult to manage in many respects and could lead to a less pleasant user experience if not done carefully (especially if the download may be interrupted and needs to be restarted, then the old token may not be valid, etc.).
I'd go with the first suggestion as it's more reliable and easier to control and manage (ignoring technology specifics as that pattern is available in all web platforms).
You could store permission information in a database. Then each user will have their own account and permission set. Then you can set user group permissions to file groups or individual files.
This could probably also be achieved using the file permission information stored at the operating system level.
You can then have a dynamic page which takes a filename as a request and verifies a user name and password combination and checks whether that file is allowed for that person.
So when someone goes to that file link, they first have to provide the correct credentials to download, otherwise they are denied access.
I hope this helps, it wasn't a directly SilverLight answer but more language agnostic
I have an AjaxControlToolkit DynamicPopulate control that is updated by calls to a WCF service. I know I can check the HttpContext in the service request to see if a user of the page (and thus, the control) is authenticated. However, I don't want anyone clever to be able to call the service directly, even if they're logged in. I want access to the service to be allowed ONLY to requests that are made from the page. Mainly, I don't want anyone to be able to programatically make a large number of calls and then reverse-engineer the algorithm that sits behind the service.
Any clever ideas on how this can be done? Maybe I'm over-thinking this?
Thanks in advance.
The simple answer is you can't. The complicated answer is you can fudge it with a lot of work, you could for example
Rate limit based on the IP of the caller.
Drop a cookie based upon the session and rate limit on that.
Drop a cookie based upon the page when the page loads and rate limit upon that.
However none is foolproof, and all can go wrong with legitimate requests.
If you really want to restrict this to just this one server making the request, you could add a certificate to that server and check for that certificate. However, you probably can't really limit access to just a single page calling your service.
You could add a lot of additional elements, like headers etc. - but none will really be totally sound - if someone is determined enough, they'll be able to figure out what you're doing, and replicate that.
So really: why do you need to limit this access this badly?
I solved this with a different approach. Instead of trying to secure the service to a single page, I just secured the service by checking HttpContext to make sure the user making the request is authenticated. This relies on ASP.NET Compatibility being enabled on the WCF service class: http://msdn.microsoft.com/en-us/library/ms752234.aspx
Then I have access to HttpContext within the service and can check that the call came from an authenticated user. =D