Re: [PHP] Secure Communication?
tedd wrote: And then there is the security involved in what happens *if* your server is hacked and all your private data is seen by a third party. What does all that entail -- and -- how you might be able protect yourself should be paramount in every developer's mind. IMHO, not in a normal context. A developer needs to be able to trust that the server is as secure as the organisation expects. In addition, access to the database can happen if the user-name and password are kept in a file, or code, that is exposed to the hacker after hacking. Everything is exposed. If somebody gains unauthorized access to your system, assume the worst. Now, how likely is it that a server might be hacked -- again, I don't know. If it's not secured, 100%. So, if you want to secure your data on a server, it means that you should take steps to do that and not rely upon the host to do that for you. Like I said, it would be nice to have a server guru wade in on this to clarify things. There isn't really a lot to clarify. To reduce the risk of a server being compromised: impose physical access controls. limit the open services, and run a firewall. make sure your open services are secure (latest patches etc). To reduce the impact should it get compromised anyway: run your server in a DMZ. run SElinux or AppArmor for access control. do not store important passwords on the server. If all of that isn't really within your reach because you don't have your own server - get your own server and secure it. A leased server is available for e.g. EUR50/month and that money is better spent than you spending hour after hour trying to secure your application to run on an insecure server. -- Per Jessen, Zürich (10.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Re: Making multiple RSS feeds for the blog website
On Sun, Aug 29, 2010 at 04:30:08AM +0200, Michelle Konzack wrote: Hello Andre Polykanine, Am 2010-08-27 12:55:51, hacktest Du folgendes herunter: Hello Michelle, Hm. link rel=alternate... that's a good one, thanks (btw, you say me that I should RTFM, but if I knew what to read). Now there are two questions: 1. How do I do those .RSS files with PHP? All of mmy blog entries and other stuff are in MySql. There are classes that can echo the appropriate data as RSS, but there will be more .PHP files, not .RSS/.XML ones. So how do we manage that? 2. Should I make a separate .RSS file for each type of feeds (blog feed, comments feed, timeline feed, news feed)? The Internet is full of HOWTOs which explain HOW-TO-MAKE-A-RSS-FEED... However sometimes back I asked HERE IN THIS LIST the same IDIOTQUESTION! You could have searched THIS LIST... :-P I've seen sites which detail all the posts to this list. Do you know of one which has *search* capabilities? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Questions about $_SERVER
On Sun, Aug 29, 2010 at 06:04:23PM +0200, Per Jessen wrote: Jason Pruim wrote: My understanding of how shared hosting works would make this near impossible... Basically Apache grabs a header that is sent at the initial connection which includes the destination hostname and from there it translates it to the proper directory on the shared host. All the IP's though are based off of the parent site's server... Now with dedicated hosting where you have the entire machine you can do what you are looking at because the IP address will always translate back to your website. AFAICT, Tedd was not asking about the server, he's asking about the client. No, he's talking about the server. But the server he's using may offload the processing of a script to another machine. So $_SERVER['SERVER_ADDR'] and $_SERVER['SERVER_NAME'] both relate to the server which the client is originally communicating with. But he wants to know if he can get the same information about a different remote server which is processing a script for him. The problem is that we have: $_SERVER['REMOTE_ADDR'] but no $_SERVER['REMOTE_NAME'] So the question is, how would he get that last variable. It becomes complicated when using a shared hosting environment, because server names and IPs aren't a 1:1 mapping. An IP may represent numerous actual site names. This was part or all of the reason why the http protocol was revised from 1.0 to 1.1-- in order to accommodate all the domains, which because of the cramped IP space of IPv4, had to share IPs. So in the HTTP 1.1 protocol, there is additional information passed about the name of the domain. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Questions about $_SERVER
On 30 August 2010 21:32, Paul M Foster pa...@quillandmouse.com wrote: On Sun, Aug 29, 2010 at 06:04:23PM +0200, Per Jessen wrote: Jason Pruim wrote: My understanding of how shared hosting works would make this near impossible... Basically Apache grabs a header that is sent at the initial connection which includes the destination hostname and from there it translates it to the proper directory on the shared host. All the IP's though are based off of the parent site's server... Now with dedicated hosting where you have the entire machine you can do what you are looking at because the IP address will always translate back to your website. AFAICT, Tedd was not asking about the server, he's asking about the client. No, he's talking about the server. But the server he's using may offload the processing of a script to another machine. So $_SERVER['SERVER_ADDR'] and $_SERVER['SERVER_NAME'] both relate to the server which the client is originally communicating with. But he wants to know if he can get the same information about a different remote server which is processing a script for him. The problem is that we have: $_SERVER['REMOTE_ADDR'] but no $_SERVER['REMOTE_NAME'] So the question is, how would he get that last variable. It becomes complicated when using a shared hosting environment, because server names and IPs aren't a 1:1 mapping. An IP may represent numerous actual site names. This was part or all of the reason why the http protocol was revised from 1.0 to 1.1-- in order to accommodate all the domains, which because of the cramped IP space of IPv4, had to share IPs. So in the HTTP 1.1 protocol, there is additional information passed about the name of the domain. In the scenario painted, it's explicitly stated that one server acts as a client in trying to access a resource on another server. Could you enlighten me as to where the domain name of a client is located in the request header fields? Here's the RFC for HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Communication?
On Sun, Aug 29, 2010 at 12:24:31PM -0400, tedd wrote: Hi gangl: I realize that the problem stated herein has been solved by others, so I'm not claiming I've done anything new -- it's only new to me. It was a learning experience for *me* and my solution may help others. In any event, I've finished creating a method for establishing what I think is secure communication between two servers. I've written two scripts that run on different servers, which confirm communication between them via hard-wired urls and creating/writing/reading a url-confirmation file. The purpose of this exercise was to simply to keep database-access data (i.e., user_name, password, key to decryption) secret. However, the secret could be anything you want to keep secret -- secret being defined as no data residing on the server of concern while allowing that server access to the data when needed and under authorization. Here's what I've done -- I have two domains, namely webbytedd.com (the Master) and php1.net (the Slave) -- both domains reside on different servers. The domain names really don't matter, it's just that this method currently works between those two domains. Statement of Requirements: 1. The Master requires access to it's database. 2. The Slave keeps access to Master's database in it's own database. 3. It's required that access remain secret in the event that the Master is hacked. *The term access above is defined as database-access data, such as user_name, password, and key to decryption. Description of Method: 1. When the Master wants access to it's database, it first creates a url-confirmation file and writes a token to that file, which resides on the Master. I've used time() as the token, but the token could be any variable -- it really doesn't make much difference other than the value should be different each time. 2. The Master then sends a cURL request to the Slave via a POST where the POST variable contains the token. 3. The Slave when receiving the POST request from Master reads the token from the newly created url-confirmation file residing on the Master and then compares that token with the token provided by the POST -- if the tokens match, then the Slave returns the access to the Master. If not, the process fails. 4. After receiving access the Master deletes the url-confirmation file and continues with it operation. If the Master does not receive access then it deletes the url-confirmation file and exits. This method sounds simple enough and does several things. 1. There is no access stored on the Master. 2. While the Slave has access for the Master stored in its database, the access to the Slave's database is kept in an out-of-root (not open to the web) file. Note, in this case, this was not possible on the Master because the host did not allow out-of-root files -- but that is only tangential to the problem addressed here. 3. If a hacker did obtain access to the Slave database, then the hacker would discover the contents have been encrypted and only the Master has the decryption key kept in it's database. 4. If a hacker did obtain access to the code residing on the Master, then the hacker could not access the Master's database because the access data is recorded on another server (i.e., Slave). Furthermore, the hacker could not get the code to run anywhere else because the Slave's look-up URL for the url-confirmation file is hardwired to the Master address. 5. And lastly, all communication between both domains is done via https. Now, for the exception of both server's being hacked at the same time, what could go wrong? Cheers, tedd A couple of things I'm unsure about. Here's what I *think* is going on: The actual database with the Master's data is located on the Master machine. The keys to this data are contained on the Slave server, in *its* database. The Slave's database is encrypted, so that the keys to the Master database can't be derived even if a hacker hacks the Slave machine. The keys to the Slave database are held by the Master. So when the Master asks the Slave for access, it must send across the keys for the Slave to access its own database. The Slave then decodes its database and sends the Master back the keys for the Master's database. The Master can then make queries to its database unfettered. Is that about right? Other than the fact that this solution should be rife with latency issues, it seems like it would be secure. I assume you're doing this as an academic exercise. If you had an actual client who wanted to go to this much trouble to secure their data, I think I would opt for the previously suggested solution of getting a dedicated server or two. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Questions about $_SERVER
On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: On 30 August 2010 21:32, Paul M Foster pa...@quillandmouse.com wrote: On Sun, Aug 29, 2010 at 06:04:23PM +0200, Per Jessen wrote: Jason Pruim wrote: My understanding of how shared hosting works would make this near impossible... Basically Apache grabs a header that is sent at the initial connection which includes the destination hostname and from there it translates it to the proper directory on the shared host. All the IP's though are based off of the parent site's server... Now with dedicated hosting where you have the entire machine you can do what you are looking at because the IP address will always translate back to your website. AFAICT, Tedd was not asking about the server, he's asking about the client. No, he's talking about the server. But the server he's using may offload the processing of a script to another machine. So $_SERVER['SERVER_ADDR'] and $_SERVER['SERVER_NAME'] both relate to the server which the client is originally communicating with. But he wants to know if he can get the same information about a different remote server which is processing a script for him. The problem is that we have: $_SERVER['REMOTE_ADDR'] but no $_SERVER['REMOTE_NAME'] So the question is, how would he get that last variable. It becomes complicated when using a shared hosting environment, because server names and IPs aren't a 1:1 mapping. An IP may represent numerous actual site names. This was part or all of the reason why the http protocol was revised from 1.0 to 1.1-- in order to accommodate all the domains, which because of the cramped IP space of IPv4, had to share IPs. So in the HTTP 1.1 protocol, there is additional information passed about the name of the domain. In the scenario painted, it's explicitly stated that one server acts as a client in trying to access a resource on another server. Could you enlighten me as to where the domain name of a client is located in the request header fields? Here's the RFC for HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 From http://www8.org/w8-papers/5c-protocols/key/key.html: === EXCERPT === Internet address conservation Companies and organizations use URLs to advertise themselves and their products and services. When a URL appears in a medium other than the Web itself, people seem to prefer ``pure hostname'' URLs; i.e., URLs without any path syntax following the hostname. These are often known as ``vanity URLs,'' but in spite of the implied disparagement, it's unlikely that non-purist users will abandon this practice, which has led to the continuing creation of huge numbers of hostnames. IP addresses are widely perceived as a scarce resource (pending the uncertain transition to IPv6 [DH95]). The Domain Name System (DNS) allows multiple host names to be bound to the same IP address. Unfortunately, because the original designers of HTTP did not anticipate the ``success disaster'' they were enabling, HTTP/1.0 requests do not pass the hostname part of the request URL. For example, if a user makes a request for the resource at URL http://example1.org/home.html, the browser sends a message with the Request-Line GET /home.html HTTP/1.0 to the server at example1.org. This prevents the binding of another HTTP server hostname, such as exampleB.org to the same IP address, because the server receiving such a message cannot tell which server the message is meant for. Thus, the proliferation of vanity URLs causes a proliferation of IP address allocations. The Internet Engineering Steering Group (IESG), which manages the IETF process, insisted that HTTP/1.1 take steps to improve conservation of IP addresses. Since HTTP/1.1 had to interoperate with HTTP/1.0, it could not change the format of the Request-Line to include the server hostname. Instead, HTTP/1.1 requires requests to include a Host header, first proposed by John Franks [Fra94], that carries the hostname. This converts the example above to: GET /home.html HTTP/1.1 Host: example1.org If the URL references a port other than the default (TCP port 80), this is also given in the Host header. Clearly, since HTTP/1.0 clients will not send Host headers, HTTP/1.1 servers cannot simply reject all messages without them. However, the HTTP/1.1 specification requires that an HTTP/1.1 server must reject any HTTP/1.1 message that does not contain a Host header. The intent of the Host header mechanism, and in particular the requirement that enforces its presence in HTTP/1.1 requests, is to speed the transition away from assigning a new IP address for every vanity URL. However, as long as a substantial fraction of the users on the Internet use browsers that do not send Host, no Web site operator (such as an electronic commerce business) that depends on these users will give up a vanity-URL IP address. The transition,
Re: [PHP] Questions about $_SERVER
On 30 August 2010 22:34, Paul M Foster pa...@quillandmouse.com wrote: On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: On 30 August 2010 21:32, Paul M Foster pa...@quillandmouse.com wrote: On Sun, Aug 29, 2010 at 06:04:23PM +0200, Per Jessen wrote: Jason Pruim wrote: My understanding of how shared hosting works would make this near impossible... Basically Apache grabs a header that is sent at the initial connection which includes the destination hostname and from there it translates it to the proper directory on the shared host. All the IP's though are based off of the parent site's server... Now with dedicated hosting where you have the entire machine you can do what you are looking at because the IP address will always translate back to your website. AFAICT, Tedd was not asking about the server, he's asking about the client. No, he's talking about the server. But the server he's using may offload the processing of a script to another machine. So $_SERVER['SERVER_ADDR'] and $_SERVER['SERVER_NAME'] both relate to the server which the client is originally communicating with. But he wants to know if he can get the same information about a different remote server which is processing a script for him. The problem is that we have: $_SERVER['REMOTE_ADDR'] but no $_SERVER['REMOTE_NAME'] So the question is, how would he get that last variable. It becomes complicated when using a shared hosting environment, because server names and IPs aren't a 1:1 mapping. An IP may represent numerous actual site names. This was part or all of the reason why the http protocol was revised from 1.0 to 1.1-- in order to accommodate all the domains, which because of the cramped IP space of IPv4, had to share IPs. So in the HTTP 1.1 protocol, there is additional information passed about the name of the domain. In the scenario painted, it's explicitly stated that one server acts as a client in trying to access a resource on another server. Could you enlighten me as to where the domain name of a client is located in the request header fields? Here's the RFC for HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 From http://www8.org/w8-papers/5c-protocols/key/key.html: === EXCERPT === Internet address conservation Companies and organizations use URLs to advertise themselves and their products and services. When a URL appears in a medium other than the Web itself, people seem to prefer ``pure hostname'' URLs; i.e., URLs without any path syntax following the hostname. These are often known as ``vanity URLs,'' but in spite of the implied disparagement, it's unlikely that non-purist users will abandon this practice, which has led to the continuing creation of huge numbers of hostnames. IP addresses are widely perceived as a scarce resource (pending the uncertain transition to IPv6 [DH95]). The Domain Name System (DNS) allows multiple host names to be bound to the same IP address. Unfortunately, because the original designers of HTTP did not anticipate the ``success disaster'' they were enabling, HTTP/1.0 requests do not pass the hostname part of the request URL. For example, if a user makes a request for the resource at URL http://example1.org/home.html, the browser sends a message with the Request-Line GET /home.html HTTP/1.0 to the server at example1.org. This prevents the binding of another HTTP server hostname, such as exampleB.org to the same IP address, because the server receiving such a message cannot tell which server the message is meant for. Thus, the proliferation of vanity URLs causes a proliferation of IP address allocations. The Internet Engineering Steering Group (IESG), which manages the IETF process, insisted that HTTP/1.1 take steps to improve conservation of IP addresses. Since HTTP/1.1 had to interoperate with HTTP/1.0, it could not change the format of the Request-Line to include the server hostname. Instead, HTTP/1.1 requires requests to include a Host header, first proposed by John Franks [Fra94], that carries the hostname. This converts the example above to: GET /home.html HTTP/1.1 Host: example1.org If the URL references a port other than the default (TCP port 80), this is also given in the Host header. Clearly, since HTTP/1.0 clients will not send Host headers, HTTP/1.1 servers cannot simply reject all messages without them. However, the HTTP/1.1 specification requires that an HTTP/1.1 server must reject any HTTP/1.1 message that does not contain a Host header. The intent of the Host header mechanism, and in particular the requirement that enforces its presence in HTTP/1.1 requests, is to speed the transition away from assigning a new IP address for every vanity URL. However, as long as a substantial fraction of the users on the Internet use browsers that do not send Host, no Web site operator (such as an
Re: [PHP] Questions about $_SERVER
On Mon, Aug 30, 2010 at 10:34:42PM +0200, Peter Lind wrote: On 30 August 2010 22:34, Paul M Foster pa...@quillandmouse.com wrote: On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: snip $_SERVER['REMOTE_NAME'] So the question is, how would he get that last variable. It becomes complicated when using a shared hosting environment, because server names and IPs aren't a 1:1 mapping. An IP may represent numerous actual site names. This was part or all of the reason why the http protocol was revised from 1.0 to 1.1-- in order to accommodate all the domains, which because of the cramped IP space of IPv4, had to share IPs. So in the HTTP 1.1 protocol, there is additional information passed about the name of the domain. In the scenario painted, it's explicitly stated that one server acts as a client in trying to access a resource on another server. Could you enlighten me as to where the domain name of a client is located in the request header fields? Here's the RFC for HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 From http://www8.org/w8-papers/5c-protocols/key/key.html: snip My mistake, though: this change was by no means the only reason for the creation of HTTP 1.1 Not only that, it has nothing whatsoever to do with the case at hand. The Host header field specifies the domain you're asking a resource from, not the the domain of the client. Hence, it cannot be used in any fashion to provide identification of the client doing the request, which is what Tedd wanted. Tedd was looking for the server name for the remote server, as seen from the perspective of the asking server. In his example, he was looking for a variable which would tell him Slave's name from Master's perspective. That's why he was asking if there was anything like $_SERVER['REMOTE_NAME'] as a known PHP server variable. Of course, you're correct in that the HTTP 1.1 spec I cited wouldn't help him. I just mentioned it as being of tangential interest. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Questions about $_SERVER
On Mon, Aug 30, 2010 at 05:13:59PM -0400, Paul M Foster wrote: On Mon, Aug 30, 2010 at 10:34:42PM +0200, Peter Lind wrote: On 30 August 2010 22:34, Paul M Foster pa...@quillandmouse.com wrote: On Mon, Aug 30, 2010 at 09:53:46PM +0200, Peter Lind wrote: snip $_SERVER['REMOTE_NAME'] So the question is, how would he get that last variable. It becomes complicated when using a shared hosting environment, because server names and IPs aren't a 1:1 mapping. An IP may represent numerous actual site names. This was part or all of the reason why the http protocol was revised from 1.0 to 1.1-- in order to accommodate all the domains, which because of the cramped IP space of IPv4, had to share IPs. So in the HTTP 1.1 protocol, there is additional information passed about the name of the domain. In the scenario painted, it's explicitly stated that one server acts as a client in trying to access a resource on another server. Could you enlighten me as to where the domain name of a client is located in the request header fields? Here's the RFC for HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 From http://www8.org/w8-papers/5c-protocols/key/key.html: snip My mistake, though: this change was by no means the only reason for the creation of HTTP 1.1 Not only that, it has nothing whatsoever to do with the case at hand. The Host header field specifies the domain you're asking a resource from, not the the domain of the client. Hence, it cannot be used in any fashion to provide identification of the client doing the request, which is what Tedd wanted. Tedd was looking for the server name for the remote server, as seen from the perspective of the asking server. In his example, he was looking for a variable which would tell him Slave's name from Master's perspective. That's why he was asking if there was anything like $_SERVER['REMOTE_NAME'] as a known PHP server variable. I'm mistaken here. He's looking for the name of the server making the request, which doesn't appear to be transmitted anywhere. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
