I’m developing an UWP app for Windows 10 phone. The client request is to be able to get the HttpClient BaseAddress (Services address) from a local file located on the Host File like on desktop apps (C:\Windows\System32\drivers\etc\hosts). This is because they need to use the app on different local networks and they want to be able to change the URL manually from the file.
Any ideas? I didn’t find information about it. Basically what I need is to manually write an address in a file to be read by my app without allowing the user interact with the to file.
I see two conflicting requests in your question - being able to manually write address in a file while at the same time without allowing the user to interact with the file.
If you store such configuration anywhere in the file system, where it can be manually written to, you cannot prevent the user to do the same. You could store the file in the applications ApplicationData.Current.LocalFolder which is more secure (although a crafty user can still find a way to edit the files stored there) but you would lose the ability to make manual edits, so your app would have to contain an area that would allow the user to edit the configuration.
In any case - ability to manually edit means user can interact with the file as well.
My approach would be to ask the administrators to create a HTTP endpoint, that would always return the configuration information you require on any given network, which your app would download on startup to reconfigure itself.
Related
I have some Infopath forms. The definitions are stored at the server.
I want to publish the form to a user who doesn't have connectivity to the server.
When I copy the .xsn file to his computer. It shows this error:
"This form cannot be opened because it requires a domain permission level and it currently has restricted permission. To fix this problem, open the form from the location it was published to."
Since the InfoPath Form actually uses resources on the server that he doesn't have access to, it's not going to work in its current form.
You would need to do one of the following, in order of what I consider increasing complexity:
A) Get the user connected to the appropriate network, maybe through a VPN if he's remote.
B) Duplicate those resources on a server the user does have access to.
C) Alter the form so that it doesn't require those resources. Maybe put them inside the form.
From what I've gathered, mail won't work offline using WAMP unless set up. So right now I have users that aren't activated. I'm not able to log in(or register) to wordpress as a registered user to create a specific additional functionality. Is there a way to get around this without taking it online?
Additionally can you collect more information from a registered user via additions to the form? How much access do you have to this information? The end goal is to try and keep specific information only visible to certain registered users. Only registered users that I allow would have access.
The Online/Offline of WAMPServer only changes the access allowed to Apache
Online = Apache accepts access from any ip address
Offline = Apache only accepts connections from the local PC i.e. the one running WAMPServer
The reason you cannot send emails is that Windows does not have a mail server installed by default like a *nix system. If you want to send emails you have to install some sort of email server that PHP can pass emails to.
There are a number that you can use :
I prefer hMailServer but it is a little complicated to configure unless you understand a bit about mail servers
Alternatively you could try fake Sendmail for windows
My team have been asked to 'enhance' a web app to permit the following. Is this considered a security risk in a web app? I'm not sure about this.
"Be able to access directories, for exporting and importing [data into the database] , outside of the virtual directory"
In other words the requester wishes to be able to navigate to a data file anywhere outside the application's IIS virtual directory, presumably when importing (or exporting) data.
I think this means on the web server, but it may mean local files on the client machine (to be clarified). But either way the question stands.
If you are talking about going outside the boundaries of the web application, that means a risk. Once you allow a particular user to go beyond your web application, then there is no more control in what that user could do with the webserver.
Have a look at path traversal attacks:
https://www.owasp.org/index.php/Path_Traversal
Also, here is a list of things to consider in order to avoid this:
https://www.owasp.org/index.php/File_System#Path_traversal
Any questions, just let me know.
Regards,
Fabio
#fcerullo
The question does not stand 'either way'. They are different questions. If it is about being able to select a file from the local computer to send to the remote server then that is pretty routine. e.g. one does it all the time while attaching a file to an email. The user is the one who initiates the file choice AND it is their file to send to the web app. No security hole here.
IF you have a need to allow clients to be able to browse the server computer for all sorts of files, then that itself is NOT a security hole. That is what you wanted, you got it. It is a security hole ONLY when you did not mean that the client should be able to grab hold of files off any whichever directory on the server. This whole scenario is classified as security issue because more often than not you do NOT want clients to have access to all inclusive files on the server. Typically the client needs to be able to access only certain files. Restricting you to virtual directory is one way of doing it. e.g. would you want your clients to be able to grab hold of the actual DB files with records of all users of your web site and then load that DB file in their own DB?
If you need to go beyond that, you need to implement mechanisms in place that allow access to only certain files. Remember your web server is running in the context of some user on the server OS. When the client request comes to the server, it that that web server user under which the command executes. So you cannot achieve security by simply putting in permissions for that web server user.
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