I know authenticated internet certificate users are logged. I would like to log the internet certificate users (that are NOT in Address Book). Currently these users appear as Anonymous in the log. I want to have the user's common name associated with the certificate to appear in the log. I know the CGI variable "HTTPS_CLIENT_CERT_COMMON_NAME" will capture this.
Any ideas would be appreciated.
V/R,
Kev
You'll have to put code in your applications to do this, or write a DSAPI plugin if you want it done at the server level.
If you're looking for a solution that doesn't involve writing custom code, that's really a question for ServerFault rather than StackOverflow - but I suspect that there's no solution for that.
Related
Recently I have problem with Open Graph checkers unable to detect Open Graph data?. It turns out that the bots from the checkers are unable to access data. However, since I have no root access to my shared hosting, I can't use wireshark to know the exact bots that connects to my hosting, therefore cannot ask the technician to help me.
So is there a way to know the bots? I really have no idea where to start. The site I want to know is https://developers.facebook.com/tools/debug/og/object/
Related: What is the bot in Facebook for Developers' Object Debugger?
You can see and identify all traffic to your website in the access logs generated by apache, nginx, iss, ...
Furthermore there are already a lot of tools out there which are able to parse and reflect the data in a human reabable format. e.g. awstats
Hi Im going though and securing a site I have that runs drupal 7 using the security review module. One of the recommendations is to not use watchdog to log events to the screen I.E the data base I guess. If I turn that off would there be another secure way to send logs to my workstation so that I can monitor traffic to the site. I.E what people view, broken links and the like?
I'm on a shared host, not a dedicated host. I did a search on some different ways to do this, but I really dont know where to start. Should I download a module to do this? Or does Drupal report all this information to the server logs? Sorry if I am not formatting this question correctly, but i'm not to clear on how to do this.
Are you sure the recommandation is about Drupal's watchdog? Not about displaying error message on the pages. These are two different things.
That said, in Drupal, the watchdog is only an API to log system messages. Where the messages go, how they are actually logged, is a pluggable system. By default, Drupal uses a module called "Database logging" (dblog) to log message to the database. A syslog module is also provided, but not really an option if you are on a shared hosting. A quick search reveal modules to send messages to Logentries, Logstash (and Loggly), Slack, LogIO, email, etc.
If you have a gigantic site with millions a hits a day then, yeah, don't use watchdog.
But if it's just a small site, just use watchdog to log your events. And seeing its a shared host, it's not a high profile site. Using watchdog is fine.
Dear StackOverflow community,
======================================
TL;DR VERSION:
Before we proceed further in our relationship with a cloud web portal provider, I'd like to insist that they provide us a secure way to obtain a copy of our data from their web server.
Secure for authenticating ourselves without leaving ourselves vulnerable to having our credentials stolen or spoofed and
Secure for the file in transit on its way back to us.
I suspect I might have to point them in the right direction myself despite my own inexperience in the field. What kinds of simple-yet-secure approaches to authenticating us could I ask them to look into?
======================================
FULL POST
BACKGROUND:
At work, we are evaluating a cloud-based portal through which our current and former customers will be able to network with each other (we have customers who interact with us in cohorts).
The user interface of the portal is well-designed, which is why we're thinking about buying it, but the company providing it is young. So, for example, their idea of "helping us integrate our portal data with SalesForce" was to have a link within the administrative control panel to a page that returns a CSV file containing the entire contents of our database.
"Fetch a CSV" actually is fine, because we already do it with other CSV files from our ERP (pushing to SalesForce with a data loader and scheduled Windows batch scripting on an always-on PC).
I said we could work with it as long as they provided us a way to fetch the CSV file programmatically, without human intervention, at 5AM. They did so, but the solution seems vulnerable to exploitation and I'd like guidance redirecting their efforts.
A DIVERSION ABOUT THE HUMAN UI:
The link one sees as a human using the web interface to the portal under consideration is http://www.OurBrandedDomain.com/admin/downloaddatabase
If you aren't already logged in, you will be redirected http://www.OurBrandedDomain.com/Admin/login?returnUrl=admin/downloaddatabase , and as soon as you log in, the CSV file will be offered to you.
(Yes, I know, it's HTTP and it's customer data ... I'm planning to talk to them about turning off HTTP access to the login/signup forms and to the internals of the site, too. Not the focus of my question, though.)
THEIR PROPOSAL:
So, as I said, I asked for something programmatically usable.
What they gave us was instructions to go to http://www.OurFlavorOfTheirSite.com/admin/fetchdatabase?email=AdminsEmail#Domain.com&password=AdminsPassword
Please correct me if I'm wrong, but this seems like a really insecure way to authenticate ourselves to the web server.
HOW I NEED HELP:
Before we proceed further in our relationship with this portal provider, I'd like to insist that they provide us a secure way to obtain a CSV copy of our data.
Secure for authenticating ourselves without leaving ourselves vulnerable to having our credentials stolen or spoofed and
Secure for the file in transit on its way back to us.
However, I don't get the sense that they've really thought about security much, and I suspect I might have to point them in the right direction myself despite my own inexperience in the field.
What kinds of simple-yet-secure approaches to authenticating us could I ask them to look into, knowing nothing more about the architecture of their servers than can be inferred from what I've just described here?
The solution doesn't have to involve us using a browser to interact with their server. Since we'll be downloading the file in a Windows scripting environment without human intervention, it's fine to suggest solutions that we can only test programmatically (even though that will make my learning curve a bit steeper).
(I suppose the solution could even get away from the server providing the data in the form of a CSV file, though then we'd probably just end up rebuilding a CSV file locally because we have infrastructure in place for CSV->SalesForce.)
Thanks in advance.
Yes, that is insecure.
You should insist on using TLS. For this they need to install a certificate from a Certification Authority to verify that they own the domain OurFlavorOfTheirSite.com. This will enable the URL to use HTTPS which means communication is encrypted, and authenticated (i.e. another website cannot spoof OurFlavorOfTheirSite.com without a browser warning being displayed).
Although the email=AdminsEmail#Domain.com&password=AdminsPassword parameters will be encrypted, these should be submitted via POST rather than GET. The reason is that GET query string parameters are logged in browser history, logged in proxy and server logs by default and can be transmitted in the referer header when resources are included from other domains.
We currently have a B2B website available over the public internet that is accessed by thousands of authenticated users worldwide from any location. We would like it so each user can only access the website from one computer (for security and license reasons). We currently use a Java applet on the site that obtains the user's MAC address but it's obstructive and that value can be spoofed so we are looking to move away from this implementation.
What is the best way to limit usage of a website to a single computer? Is this something that's best left to a security vendor, do we need to have users install certificates on their machines or are there other solutions available? Any advise on this topic is appreciated. Thanks.
Update: What we would like to do is implement some kind of device authorization for the website. I thought I saw some banking websites do this kind of thing...does anyone by chance know what approaches can be taken it accomplish such functionality? Perhaps virtual tokens or some other multi-factor authentication implementation?
There won't be a solution to this that you like.
By design, web browsers have very limited access to the containing computer. In the spirit of 'on the internet no one knows that you are a dog', your side can't ever find out much about the other end. The IP address is subject to NAT and other spoofing. An X.509 certificate is perfectly portable from one computer to another.
Essentially, the conceptual model of the entire 'web' does not include 'computers'. If you are a server, you get a connection, and you can ask it very few questions indeed. None of them amount to 'give me a unique token that identifies a computer on the other end'.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
If I had let's say a sensitive report in PDF format and wanted to send it to someone, what is the most secure way?
Does a desktop application make it more secure? Since we are basically doing a client to server communication via private IP address? Then add some kind of standard encryption algorithm to the data as you send it over the wire?
What about a web based solution? In web based, you have a third person in the loop. Sure, it would do the same kind of encryption that I would have on a desktop.. but now instead of client->server directly, you have client->server | server<- client... You also have exposure to the broad internet for any intruders to jump in, making yourself more open to man-in-middle attack... One thing the web has going for it is digitial certificates but I think that is more authentication than authorization.. which the desktop problem doesnt have?
Obviously from a usability point of view - a person wants to just goto a web page and download a report he's expecting. But most secure? Is desktop the answer? Or is it just too hard to do from a usability perspective?
OK there seems to be some confusion. I am a software engineer and am facing a problem where business users have some secure documents that they need to distribute - I am just wondering if using the web and SSL/CA is the standard solution to this, or maybe a desktop application could be the answer??
The method that comes to mind as being very easy (as in it has been done a lot and is proven) is just distributing via a web site that is secured with SSL. It's trivial to set up (doesn't matter if you're running Windows, *nix, etc) and is a familiar pattern to the user.
Setting up a thick client is likely more work because you have to do the encryption yourself (not difficult these days, but there is more to know in terms of following best practices). I don't think that you'll gain much (any?) security from having to maintain a significantly larger set of code.
Most secure would be print it, give it to a courier in a locked briefcase, and have the courier hand deliver it. I think that'd be going overboard, though :)
In real world terms, unless you're talking national security (in which case, see courier option above), or Trade Secrets Which Could Doom Your Company (again, see courier option above), having a well encrypted file downloaded from the web is secure enough. Use PGP encryption (or similar), and I recommend the Encrypt and Sign option, make the original website a secure one as well, and you're probably fine.
The other thing about a desktop application is: how is it getting the report? If it's not generating the report locally, it's really doing just as many steps as a web page: app requests report, report generated, server notifies client, client downloads.
A third option, though, is to use something other than the website to download the reports. For instance, you could allow the user to request the report through the web, but provide a secure FTP (SFTP or FTPS) site or AS2 (or AS3) connection for the actual download.
Using a secure file transfer (or managed file transfer) is definitely the best option for securely transferring electronic data. There are smaller, more personal-use solutions out there like Dropbox or Enterprise solutions like BiscomDeliveryServer.com
Print it off, seal it in an envelope, hire some armed guards for protection and hand deliver it to them.
You may think its a silly answer, but unless you can identify what your threat vectors are any answer is pretty meaningless, since there is no guarantee it will address those threats.
Any system is only as secure as it's weakest link. If you sent the document securely and the user downloaded / saved it to their desktop then you'd be no better off than an unsecure system. Even worse they could get the docuemnt and then send it onto loads of people that shouldn't see it, etc. That leads on to a question whether you have an actual requirement that they can only view and not download the document? If not, why go to all this effort?
But if they are able to down load it, then the most secure method may be to send them an email telling them that the document is available. They then connect to a system (web / ftp?) using credentials sent separately to authenticate their access.
I'm surprised no one has mentioned a PK-encryption over email solution. Everyone in the "enterprise" gets a copy of everyone else's public key and their own private key. Lots of tools exist to do the heavy-lifting. Start with PGP and work from there.