php-general Digest 4 Sep 2010 16:45:28 -0000 Issue 6924
Topics (messages 307841 through 307847):
Re: PHP, Soap, and WDSL
307841 by: Jangita
307842 by: chris h
307843 by: SBS Computers
Re: Questions about $_SERVER
307844 by: tedd
Re: Secure Communication?
307845 by: tedd
307846 by: tedd
a test (list is too quite)
307847 by: tedd
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 02/09/2010 10:51 p, SBS Computers wrote:
It's as if the data is not getting to my php page?
The view source shows the following data:
<?xml version="1.0" encoding="utf-16"?><soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
.
.
.bunch of data
.
.
</response></soap:Body></soap:Envelope>
Seems like the data is getting there OK. But a browser normally will not
output normal xml and hides it (unless there is a <body /> tag or other
tags that normally display output since it is using the text/html MIME
add this line
header('Content-type: text/plain');
before the echo and see what happens. Also make sure there is no other
output (echo or any html tags) before the line above
--
Jangita | +256 76 91 8383 | Y! & MSN: jang...@yahoo.com
Skype: jangita | GTalk: jangita.nyag...@gmail.com
--- End Message ---
--- Begin Message ---
Alternatively you can pass the var through htmlspecialchars...
echo htmlspecialchars( $response );
and for a really simple solution you can echo it inside a textarea...
echo "<textarea> $response </textarea>";
Though you'll likely want to increase the size of the textarea! ;-)
Chris.
On Fri, Sep 3, 2010 at 3:39 AM, Jangita <jang...@jangita.com> wrote:
> On 02/09/2010 10:51 p, SBS Computers wrote:
>
> It's as if the data is not getting to my php page?
>>
>> The view source shows the following data:
>>
>> <?xml version="1.0" encoding="utf-16"?><soap:Envelope xmlns:soap="
>> http://schemas.xmlsoap.org/soap/envelope/";>
>> .
>> .
>> .bunch of data
>> .
>> .
>> </response></soap:Body></soap:Envelope>
>>
>> Seems like the data is getting there OK. But a browser normally will not
> output normal xml and hides it (unless there is a <body /> tag or other tags
> that normally display output since it is using the text/html MIME
>
> add this line
>
> header('Content-type: text/plain');
>
> before the echo and see what happens. Also make sure there is no other
> output (echo or any html tags) before the line above
>
> --
> Jangita | +256 76 91 8383 | Y! & MSN: jang...@yahoo.com
> Skype: jangita | GTalk: jangita.nyag...@gmail.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Thanks guys.
Both methods worked.
Gino
> Date: Fri, 3 Sep 2010 08:31:06 -0400
> From: chris...@gmail.com
> To: jang...@jangita.com
> CC: php-gene...@lists.php.net
> Subject: Re: [PHP] PHP, Soap, and WDSL
>
> Alternatively you can pass the var through htmlspecialchars...
>
> echo htmlspecialchars( $response );
>
>
> and for a really simple solution you can echo it inside a textarea...
>
> echo "<textarea> $response </textarea>";
>
>
> Though you'll likely want to increase the size of the textarea! ;-)
>
>
>
>
> Chris.
>
>
>
> On Fri, Sep 3, 2010 at 3:39 AM, Jangita <jang...@jangita.com> wrote:
>
> > On 02/09/2010 10:51 p, SBS Computers wrote:
> >
> > It's as if the data is not getting to my php page?
> >>
> >> The view source shows the following data:
> >>
> >> <?xml version="1.0" encoding="utf-16"?><soap:Envelope xmlns:soap="
> >> http://schemas.xmlsoap.org/soap/envelope/";>
> >> .
> >> .
> >> .bunch of data
> >> .
> >> .
> >> </response></soap:Body></soap:Envelope>
> >>
> >> Seems like the data is getting there OK. But a browser normally will not
> > output normal xml and hides it (unless there is a <body /> tag or other tags
> > that normally display output since it is using the text/html MIME
> >
> > add this line
> >
> > header('Content-type: text/plain');
> >
> > before the echo and see what happens. Also make sure there is no other
> > output (echo or any html tags) before the line above
> >
> > --
> > Jangita | +256 76 91 8383 | Y! & MSN: jang...@yahoo.com
> > Skype: jangita | GTalk: jangita.nyag...@gmail.com
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
--- End Message ---
--- Begin Message ---
Peter and Paul:
Sorry, I went on vacation for a few days (it was a surprise vacation
with a 2 day notice).
I think you both understand what I was looking for and found what I
wanted was not possible. It's just one of those things in life you
have to live with.
Thanks very much for your time and comment.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
At 3:58 PM -0400 8/30/10, Paul M Foster wrote:
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:
You got the method correct -- unfortunately, it's not as secure as I need.
As for it being an "academic exercise", nothing is academic. If it
works, it's implemented, if not, it isn't. That's what we do for a
living.
I will say it was learning experience, in that aspect it was "academic". :-)
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
At 2:23 AM +0200 8/30/10, Bostjan Skufca wrote:
Hi tedd!
Reading this thread I assume you are doing RPC stuff when you are
expressing yourself as "the access" to database, which normaly
describes direct access to database.
In your case, you should divide the phrase "hacked server" into two
separate types of incidents (let's talk about your "master" server
here):
1) server gets cracked and your code gets exposed in read only mode
2) server gets cracked and cracker can modify your code
(read the definitions of hacker vs cracker for further communication:)
In case 2) there is not much you can do, because they have
everything they need to access database in a fashion of their desire.
However, in a case 1) your protection works fine. But it is wheel
reinvented, for 99% of a population. Why?
When most of people are thinking of security, one of the first
thoughts is getting off shared hosting. When you do that, all you
need to set up is two way SSL authentication and IP checking. Which
could be done without the RPC layer (for example MySQL can check
cert against with host IP, cert against CA and CN checking and all).
Anyway, what you are trying to achieve is to connect two systems
which are shared hosting based. In this case your solution is
somehow "secure", if there is such a thing. That means that it is
secure by it's nature. But what you have to be careful about is
implementation and things that are out of scope of setup you have
described.
One possible breach of your "secure" setup is here: on your master
server (shared hosting) HTTP server runs PHP scripts as single user
(usually www-data, www or nobody). Your script HAS to have writable
permissions to folder where it publishes tokens. Should malicious
user have an account on the very same machine, she can also put
files in folder where only you should be able to do so. This way,
she can publish token, request stuff from your database and decrypt
it using your keys.
I hope I have understood your intentions correctly. Best regards,
b.
PS: Probability of hacked server.
From my experience majority of successfull breaches come from 3
methods (in order of decreasing frequency):
- password collection with viruses/trojans and such (operates
against client machine)
- stupid users writing passwords all around (post-it, forwarded
email, etc) and/or social engineering (operates against user)
- brute force password guessing (operates against server)
Only tiny fraction of breaches are whole servers being hacked/rooted.
Hi Bostjan:
A very detailed and correct analysis of what I was trying to achieve.
Your comments are well said,appreciated, and acknowledged.
I was hoping for a solution, but I see there is none.
Thanks,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
Hi gang:
Just checking to see if I am still receiving postings. :-)
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
