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.
Related
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.
I notice that some sites are coping the content of one of my client's sites using automated agents. I want to detect their requests and show them a captcha code to prevent them from coping the site content.
Is there anyway to detect them?
This is a complex problem and a game of cat and mouse. To make it slightly difficult:
Ban the IPs that are hitting the site repeatedly, a normal user would not need ALL the pages
Ban public proxies, list is available on googleing
Any request from banned IPs/Proxies should be redirected to captcha page
Typically an "automated agent" would be accessing a lot of data in a short period...more than a typical user. You would need to setup something to track ip addresses of all users and see if there is any such ip that stands out and block them.
Of course, this is made more difficult as there are proxies and dynamic ips etc...
We have two websites with different domain names. One of them is a wordpress site. Both websites have their own authentication system.
For the sake of convenience, it was decided to have a single authentication for both website and making use of session cookies. I searched about it and got to know about Single Sign On. Can anybody tell me how to implement SSO when one of the website is a wordpress site(if this makes any difference)? I would highly appreciate if any help comes.
Pretty simple actually. From the non-wordpress site, you just need to make the login form connect to the wordpress database and check the user-provided credentials. Wordpress uses an md5 password hash, so make sure you hash the users password with the md5() function before passing it to the database. Handle the return results as normal.
One note, make sure that your database user has permissions from the connecting host. If both sites are hosted on the same server (and IP), it won't be an issue regardless. If not, you need to make sure the database user either has permissions from the second IP or from everywhere ('user'#'%').
I would like to create web application with admin/checkout sections being secured. Assuming I have SSL set up for subdomain.mydomain.com I would like to make sure that all that top-secret stuff ;) like checkout pages and admin section is transferred securely. Would it be ok to structure my application as below?
subdomain.mydomain.com
adminSectionFolder
adminPage1.php
adminPage2.php
checkoutPagesFolder
checkoutPage1.php
checkoutPage2.php
checkoutPage3.php
homepage.php
loginPage.php
someOtherPage.php
someNonSecureFolder
nonSecurePage1.php
nonSecurePage2.php
nonSecurePage3.php
imagesFolder
image1.jpg
image2.jpg
image3.jpg
Users would access my web application via http as there is no need for SSL for homepage and similar. Checkout/admin pages would have to be accessed via https though (that I would ensure via .htaccess redirects). I would also like to have login form on every page of the site, including non-secure pages. Now my questions are:
if I have form on non-secure page e.g http://subdomain.mydomain.com/homepage.php and that form sends data to https://subdomain.mydomain.com/loginPage.php, is data being send encrypted as if it were sent from https://subdomain.mydomain.com/homepage.php? I do realize users will not see padlock, but browser still should encrypt it, is it right?
EDIT: my apologies.. above in bold I originally typed http but meant https, my bad
2.If on secure page loginPage.php (or any other accessed via https for that instance) I created session, session ID would be assigned, and in case of my web app. something like username of the logged in user. Would I be able to access these session variable from http://subdomain.mydomain.com/homepage.php to for example display greeting message? If session ID is stored in cookies then it would be trouble I assume, but could someone clarify how it should be done? It seems important to have username and password send over SSL.
3.Related to above question I think.. would it actually make any sense to have login secured via SSL so usenrame/password would be transferred securely, and then session ID being transferred with no SSL? I mean wouldnt it be the same really if someone caught username and password being transferred, or caught session ID? Please let me know if I make sense here cause it feels like I'm missing something important.
EDIT: I came up with idea but again please let me know if that would work. Having above, so assuming that sharing session between http and https is as secure as login in user via plain http (not https), I guess on all non secure pages, like homepage etc. I could check if user is already logged in, and if so from php redirect to https version of same page. So user fills in login form from homepage.php, over ssl details are send to backend so probably https://.../homepage.php. Trying to access http://.../someOtherPage.php script would always check if session is created and if so redirect user to https version of this page so https://.../someOtherPage.php. Would that work?
4.To avoid browser popping message "this page contains non secure items..." my links to css, images and all assets, e.g. in case of http://subdomain.mydomain.com/checkoutPage1.php should be absolute so "/images/image1.jpg" or relative so "../images/image1.jpg"? I guess one of those would have to work :)
wow that's long post, thanks for your patience if you got that far and any answers :) oh yeh and I use php/apache on shared hosting
If the SSL termination is on the webserver itself, then you'll probably need to configure seperate document roots for the secure and non-secure parts - while you could specify that these both reference the same physical directory, you're going to get tied in knots switching between the parts. Similarly if your SSL termination is before the webserver you've got no systematic separation of the secure and non-secure parts.
Its a lot tidier to separate out the secure and non-secure parts into seperate trees - note that if you have non-SSL content on a secure page, the users will get warning messages.
Regards your specific questions
NO - whether data is encrypted depends on where it is GOING TO, not where it is coming from
YES - but only if you DO NOT set the secure_only cookie flag - note that if you follow my recommendations above, you also need to ensure that the cookie path is set to '/'
the page which processes the username and password MUST be secure. If not then you are exposing your clients authentication details (most people use the same password for all the sites they visit) and anyone running a network sniffer or proxy would have access.
Your EDIT left me a bit confused. SSL is computationally expensive and slow - so you want to minimise its use - but you need to balance this with your users perception of security - don't keep switching from SSL to non-SSL, and although its perfectly secure for users to enter their details on a page served up by non-SSL which sends to a SSL page, the users may not understand this distinction.
See the first part of my answer above.
C.
What is common practice for coding web applications where part of the site has to be secured (e.g. checkout section) and part not necessarily, let's say homepage? As far as I know sharing sessions in between HTTP and HTTPS parts of the site is not easily possible (or is it?). What would be common approach if I wanted to display on HTTP page like homepage, shopping cart data (items) that users ordered on HTTPS pages? How those two parts of the site would communicate if necessary? Also isn't it security flaw in popular shopping carts as it seems that many of these have only checkout pages secured (SSL) and the rest not?
I'm using PHP if it makes any difference.
The simplest answer is to have all links to your "secure" pages link to https://. Obviously this can be somewhat of a nightmare depending on the site.
Another alternative is to set up URL rewrite rules to automatically direct secure pages to https:// if trying to access them via http://
Check out mod_rewrite for Apache if you are not familiar with the concept. Depending on what web server you are using there are other options available to achieve the same functionality, but that should give you an idea of what your options are. I assume since you're using PHP that you're using Apache, but could not be the case?
I would say that is probably the most common approach. If all of the secure pages reside in a given directory, that makes it even easier as you can write rules to say that everything in that directory must be requested via https://, otherwise http:// is suitable.
Its pretty common practice to use cookies to store cart data throughout a site. Security isn't an issue because you only care about your credit card data going over the wire. The list of things I want to buy isn't particularly sensitive.
I can tell you what I did for an ecommerce site I created from scratch. His whole site is HTTP, which includes checking out with a check (ie they fill in their info, an invoice is generated and a check is snail mailed to the seller). But, the credit card processing is done on Paypal's side, which is HTTPS. But, in order to get the cart data to Paypal I used hidden post elements, and Paypal did the rest.
Not the greatest system, but it works.