I just go through Google search before posting this question here but I am not happy with my Google results. I hope someone can help me here.
I have an eCommerce site. All the images are stored in a different ftp server. I need to show all the images on my webpage. When page laods it ask for FTP username and password. I can avoid it by giving username and password in FTP URL. But I do not think it is secure. My password will be accessible to every user of my site.
Is there any other way?
You really should create an FTP account that only has access to the folder with the images on your FTP server. Do that as soon as possible.
For a better overall solution, either synchronize the images to your webserver, or write an HTTP handler that will fetch the image server-side and streams the bytes to the client as if the image was on your server. Have a look at System.Net.FtpWebRequest for the second solution.
If you have write access to disk on the web server, you could implement both parts of the solution. So if an image is fetched the first time, write it to disk before sending it to the client. The next time it's requested, simply redirect the request to the image on disk (or dynamically change the URL of the <img> tag for that product). This way, you build a cache of the images on your web server as time passes. Of course, you need to be able to invalidate the cache in case an image is updated.
Related
If I set up a simple web server online (eg nginx), and generate a very large random string (such that it is unguessable), and host that endpoint on my domain, eg
example.com/<very-large-random-string>
would I be safe in say, hosting a webapp at that endpoint with no authentication to store my personal information (like a scratch-pad or notes kind of thing)?
I know google docs does this, is there anything special one has to do (again, eg for nginx) to prevent someone from getting a list of all available pages?
I guess I'm asking is there any way for a malicious actor to find out about the existence of such a page, preferably irrespective of what web-server I used.
I'd be pretty alarmed if my online bank started using this system, but it should give you a basic level of security. Bear in mind that this is security through obscurity, which is rather frowned upon and will immediately turn into no security whatsoever the moment someone discovers the hidden URL.
To prevent this from happening, you will need to take a few precautions:
Install an SSL certificate on your server, and always access the url via https, never via http (otherwise the URL path will be sent in plain view and visible to everyone along the way).
Make sure your secure document contains no outgoing links. This includes not only hyperlinks (<a href="...">) but also embedded images, stylesheets, scripts, media files and so on. Otherwise the URL will be leaked to other domains via the Referer request headers.*1
(A bit of a no-brainer, but) make sure there are also no inbound links to this page. Although they aren't so common now, web hosts used to generate automatic "web stats" pages showing the traffic to each web domain. Some content management systems generate a site map automatically. This would be just as bad.
Disable directory browsing on your server. In other words, make sure that someone who visits the directory level above your hidden directory isn't presented with a list of subdirectories.
Bear in mind that the URL will always be visible in your address bar and browser history, and possibly in other places like your browser's cookie jar. Your browser will probably provide the rest of the URL by auto-complete when someone types the domain into your address bar.
*1: Actually, your browser will only send a Referer header when you access other https pages, but still...
I'm building a site for a client in Wordpress and I want to know if there's a recommended and secure way for files to be sent.
My client wants to allow her users to send her pictures as part of the service she offers.
Is there a way this can be done and more importantly, securely?
I'm open to alternative suggestions, just didn't want to pull the user away from the site to send via email (even though that will be an option also).
Thanks in advance.
My understanding is that as long as your site has SSL (preferably across the whole domain, but at least on the particular page) and you use the proper element (<input type="file" name="picture-file">) it's secure.
I allow the user to upload an xml file. From security perspective, what should I do? I want to prevent the user from uploading more than three times per day. I am looking for any suggestions about the security issues.
Basic sanity check on file size
Avoid validating using DTD or XSD. If you must, be sure to read about "XML bombs". Also, XSDs may be downloaded from the internet. An attacker may input a XSD url that takes forever to load, leading to a DOS
Verify the XML based on your business rules, and DELETE it from the hard disk if it doesn't pass you verifications.
If you save the files on your server, make sure the directory doesn't have execute permissions
Its a good idea to rename the file to a random name, so even if the file is "abc.xml", it will be saved as abc-433fdsadf3234234.xml on the hard-disk.
Do NOT allow the user to download the file that he uploaded via an anonymous URL. If you can, prevent downloads of uploaded files. If you cannot, use a throw-away domain or serve the file using ip address. This is to prevent content sniffing errors. Even if you set the content-type, some browsers can be fooled into thinking the document is HTML. This then allows the attacker to insert javascript code that can be executed by the browser.
EDIT :
Some more information on content-type sniffing
Lets say an attacker uploads an XML file that contains HTML in the first few lines. When a user downloads this XML, it is possible to trick the browser into thinking this XML is HTML.
Once you have fooled the browser, an attacker can execute javascript on the users browser. A simple example can be stealing the session cookies.
Putting it together, this is how the attack works -
1. Attacker uploads XML that has javascript code in it
2. Attacker sends the download link to another user who is the victim
3. Attacker can now execute javascript on the victims browser and steal his cookies
To prevent this - a) Validate the XML per your schema, b) Don't allow the user to download files that were uploaded, c) Serve the file from an ip address or a domain different than your regular domain - so that cookies cannot be stolen. You can read similar information over here - https://security.stackexchange.com/questions/8587/how-can-i-be-protected-from-pictures-vulnerabilities
Basic steps:
Require the users to have an account and be logged in before allowing them to upload any files
Count the number of files they upload each day
Don't allow them to upload another file if they have reached the limit.
Other than that, there are TONS of things to think about regarding security of uploading files, but none of the security things has anything to do with uploading only a certain number of files.
Limit the size of the file they can upload (reduces risk of a DDOS on the service)
Run it through a validation routine before consuming it (reduces risk of a DDOS on consumption of an invalid file)
Require authentication on the upload handler (reduces risk of unwanted files thrown your way)
Set a limit on the amount of time an upload can take (this reduces the risk of a DDOS on the service)
Ideally, if you are expecting an xml file of a specific schema, then see if the file presented validates against that schema rather than just as xml, and reject it if it does not.
Just a few to get you started.
You need to identify your users somehow, you generally have two ways:
using session identifier (stored in the cookie by default). This can be easily bypassed if the user deletes his cookies
by authenticating your user.
When your user is identified, you can extend your controller action method by business logic to check how many times that user uploaded file. And the rest can be same as the following article how to upload files in asp.net mvc.
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 have a web application that is secured and stores user detail information in a session object. I am building a Silverlight control to view images that are stored in the database and access to those images needs to be secured. I am not trying to prevent copying or anything like that but I need to make sure that the user accessing the image actually has access to view the image which can be achieved by checking the user data in the session.
So my thoughts were to do the following:
Web Application that has hosts the Silverlight control.
A ashx file to handle the serving up of the image from the database.
The ashx file when accessed via the silverlight control will check the session to make sure they do have access to this image. (I am assuming the silverlight control and web app share the same session, this could be a wrong assumption.)
Does this setup sound correct or are there other ways of approaching this? This will be my first time integrating a Silverlight control into a web application.
THe silverlight control lives within the context of the browser. I think that if you're silverlight control callse your ashx page, the ashx page will execute under the same session that your web application is running.
When a user logs into your web application, store something in the session to indicate they are authenticated, and check it in your ashx page.
It is a simple scenario to mockup and test.
Sounds like you want to ensure that nobody is sniffing traffic to determine the URL to your ashx path. Perhaps you don't want that URL being used independently from your page, or for other images that the user/caller shouldn't be seeing.
Have you considered leaving a cookie value for the client? Perhaps a scenario like this:
when your customer visits the page, it sounds like you want to load an image into a Silverlight control. At the time that you're processing the other data on the page, send a cookie value back to the browser.
drop a salted/hashed value in a cookie based on the browser/caller AND the image being requested.
Let's say that the image is someImage.png, and the client's IP address is 10.10.10.10. Use some salt like the image's db identifier to ensure uniqueness between images. Let's pretend it has ID 509.
Run the string "509_someImage.png_10.10.10.10" through a one-way encryption method (i.e. AES) using a strong key that you keep secret on your end. Let's pretend that your result is 'biglongcrazyrandomstring123', but it will obviously be much longer.
on the querystring to the call to the image.ashx page, force the include of that value (i.e. image.ashx?img=someImage.png&key=biglongcrazyrandomstring123).
On the server side, you go to your DB and retrieve the ID for someImage.png. Run the requestor's IP address, the image file name, and the database ID through the same encryption algorithm. Compare THAT value with the value sent in the querystring. If they match, then you know that YOU put the string in their cookie. Rather, you know reasonably that they couldn't have guessed it.
If anyone tries to mess with that querystring value, it'll fail every time because you're comparing two generated values.