I have a doubt with one request/response across Web Browser and Server with SSL Certificate. Please, imagine the following case (similar question here):
I want that the server, response a HTML to the user (in his/her browser) with access to one file in the FTP, for example:
Download file
In this case, accessing with Anonymous user not generate any problem to access to this file, but if the user has a access with username and password, put this on HTML, it will not be very secure, example:
Download file
I want to prevent that this response with this username and password tag between the server and the user would be catched by "Someone" and get the Username and Password of the user.
The SSL certificate can solved this? Or the best way to do this is create a directory with username and password only with read properties?
Yes, SSL will make it more secure because your communication with the server will be encrypted. It is even better if you have a web server (an API endpoint for instance) receiving the requests from your frontend, contacting the FTP server, getting the file, and responding back with it. This way, the frontend does not need to know about the FTP server. Another good idea is to hash the password before sending it.
Serving the page containing the passwords with SSL (i.e. HTTPS) helps to protect the passwords inside the page. But, the links you provide are for FTP sites and the passwords will be sent unprotected if the user follows the FTP link since ftp:// itself does not use SSL. While there is FTP with SSL (FTPS) it is not commonly implemented in the browsers so you cannot use it. The best would be to serve the files with HTTPS too instead of FTP.
Related
Our setup is like this: we use a coldfusion 10 server, and files are on a local intranet. Users use a domain login to access any files over https. I'm interested in using html5 websockets, but the first attempt gave me an error because no credentials were supplied. Is there a way around this? If not, is there a recommended technology for this scenario?
The user does log in on the client side. If it's possible, what I'd really like to do here is pass those credentials when making the connection to the server.
you should be able to supply the authentication header to your web socket server before the elevation to web socket read that and send it back in the headers for the elevation (first frame) then when the browser connects it should have the authentication it needs.
if your using a custom authentication E.G in page not authentication header you can also do this by passing any custom header to your server.
Or mandate that the first thing your web client sends is the authentication details this could be something like {username_hash}.{password_hash} if they don't close the socket to them.
Do not do this.
You're now responsible for sending and encrypting the authentication credentials yourself, bypassing something that already works and is tested.
Anyone can snoop on an unencrypted websocket port. Use HTTPs for an intranet, use stable solutions, don't reinvent this wheel because it tickles your fancy.
In a couple of years some colleague will have to maintain this and will have to figure out how your homebrew version works versus something that's solid like plain browser authentication.
My advice: Leave this to the browser and to well-tested coldfusion libraries.
I'm new to programming generally. I have typed my css and html codes and saved in a folder. How do i upload this site to a host server. Thanks
Welcome.
To upload the files to your hosted server, you would need to use a FTP program ( File Transfer Protocol). A good free one to use would be filezilla, which a quick google search will come up for you.
Once you have downloaded filezilla you will need your server FTP settings, which you can find on your Hosted servers control panel. (They generally get you to create a username and password) you would need the FTP setting and Port with your login details, to be able to log in and start uploading your files.
One thing to be careful of, is the URL links for images/pages etc, as they may be different than if they were on your local machine.
You can use FTP (file transfer protocol) to achieve this. Download a free FTP client such as FileZilla, input your hostname and login information, and then you simply navigate to your desired server location and drag and drop.
You can read more about FTP here
https://en.m.wikipedia.org/wiki/File_Transfer_Protocol
Usually we have FTP (file transfer protocol) to send data to the server.
Softwares like Filezilla, for example, can connect and handle server's directories and files the way you want.
Anyway, you need to check the available services with your hosting service.
I have successfully set up health monitoring for logging errors on my ASP.NET web page to the Windows Event Log, a SQL Server database, and through email (Microsoft Exchange) when I specify a user name and password in the web.config file. However, if I change from specifying a user name and password to defaultCredentials="true" in web.config, I get the following error message in my Windows Event Log when it tries to generate the email:
System.Web.HttpException (0x80004005): Unable to send out an e-mail to the SMTP
server. Please ensure that the server specified in the <smtpMail> section is
valid. ---> System.Net.Mail.SmtpException: Mailbox unavailable. The server
response was: 5.7.1 Client does not have permissions to send as this sender
I am running Windows Vista on a corporate domain. My Windows login is identical to my Microsoft Exchange login. Can anyone provide some insight as to why specifying my login credentials explicitly in the web.config file works, but using defaultCredentials="true" does not? Are there any known solutions so that I can have an automated email sent through healthMonitoring without having to store my user name and password in the web.config file?
Since I earned the tumbleweed badge for this question, I doubt an answer will be of much value to anyone else; but knowing that I will inevitably fall into the same trap at a later date, I thought I would post an answer to my own question...
Authentication is not necessary for sending emails within the same domain; so instead of specifying defaultCredentials="true", I removed all fields related to authentication, and the emails began working again.
Note that this is only a partial solution. I only need to send emails to addresses within the same domain for now. Sending emails outside of this domain will not work without authentication, so if/when that is needed, it will be back to the drawing board...
I've been asked to change all of our current Joomla sites from using PHP Mail to SMTP.
The background: we were recently compromised through a vulnerable component on one of our sites. We have a dedicated server, running CPanel. The hack involved a file being uploaded to one account, which had a file manager (with access to /home, ie. all other accounts). From there, another file was uploaded that began sending emails - not enough to catch with ease, but eventually enough to get our main server IP blacklisted. Because the main IP was blacklisted, many of our other sites (for which we also host email) were also blacklisted.
My argument (your comments/ideas on this are much appreciated!)
Changing to SMTP will not solve this instance
It would solve the issue of any vulnerable components where an email can be sent via a request spoof (ie. option=com_users?task=email&..., or something similar to that)
Because the hacker has access to the files in the account, they also have access to the configuration.php file, which holds the SMTP password in plain text. Access to this means they would also have access to the SMTP server.
The SMTP that we would be using is localhost, which doesn't solve the issue of our IP being blacklisted.
My first idea was to provision/setup SMTP on a separate IP (or server), but that can still be blacklisted if a site gets hacked.
The second idea was to provision each site a unique IP, so no one site can get the rest blacklisted.
So I'm a bit lost. Before we tackle the task of setting the mailing function to SMTP, testing each site (there's roughly 70, with varying components to test) I'd like to have a better idea of what's the best route, if any.
It seems that either setting in Joomla is insecure in the event of a compromised site, no?
Find where your server is blacklisted, and apply to be removed. Note: if any of the sites require payment to be de-listed, ignore them. [eg: SORBS] Nobody cares about extortionists, trust me. I was admin for several busy mail servers for the last few years.
If you're completely switching from PHP-based mail() on all sites, then disable the mail agent on the server. mail() simply submits to the MTA running on the server [usually Sendmail or Postfix] and if your server is compromised again they will still be able to spam out.
Yes, your SMTP credentials will be stored in a config file somewhere, but most instances the intruder won't even bother to look for them. They simply drop in a basic PHP script that calls mail() and that's it.
If mail service is at all important to you you should always monitor:
The reputation of your outbound server.
The abuse mail for your domain. It will either be coming to abuse#yourdomain.com, or the abuse# contact for whoever owns the IP address block.
I have a server with Plesk installed.
On that I've created a domain, my-domain.com, and added and e-mail account noreply#my-domain.com with access to SMTP for sending e-mails.
With PHPMailer or Swift Mailer I am able to send via the SMTP account noreply#my-domain.com whenever the from address is outside the my-domain.com, for example info#my-second-domain.com.
Whenever I'm using an e-mail address that ends on #my-domain.com it fails.
I've tried to look in the /usr/local/psa/var/log/maillog file, but it only stores the mails that doesn't fail.
Can someone help me figure out where the problems is?
You can try this:
Delete the related domain in the qmail file /var/qmail/control/virtualdomains
Then reload/restart qmail. Now it should work.
More technical background at http://forum.parallels.com/pda/index.php/t-93222.html
Benjamin answer didn't work on my installation (Plesk 11.5), but I found another solution:
just turn off the mail service itself. It might not be the solution for everyone but it was for me (my domain's mx records pointing to another server, with some scripts sending emails here and there).
You can turn off the mail service fairly easily using Plesk GUI.
Then uncheck
However, this won't turn it off for subdomains and secondary domains you might have. No problem, just log in with ssh and run this command:
/usr/local/psa/bin/domain -u mydomain.example.com -mail_service false
And if one day you decide you want to turn it back on just replace false by true.