Hi!
I'm pondering on a problem here. Being a C/C++, Java and Visual Basic developer, the
aspect of reverse engineering code from (compiled) programs, hasn't occupied my mind
that much.
Now, developing PHP scripts on large scale I have started to think otherwise. How do
you all secure your
[snip]
I'm pondering on a problem here. Being a C/C++, Java and Visual Basic
developer, the aspect of reverse engineering code from (compiled)
programs, hasn't occupied my mind that much.
Now, developing PHP scripts on large scale I have started to think
otherwise. How do you all secure your code?
--- Video Populares et Optimates [EMAIL PROTECTED] wrote:
I'm pondering on a problem here. Being a C/C++, Java and Visual Basic
developer, the aspect of reverse engineering code from (compiled)
programs, hasn't occupied my mind that much.
Now, developing PHP scripts on large scale I have
Yes, I've had that thought also. I believe that the question you suggest
will probably the foundation of the main course I'll take. For what
possibilities are there really to hide anything in plain text that anyway
will reside on third-party servers. (rhetorical question)
You can never know what
If you mean to protect your source from your users, that is the case
already. Unless someone can compromise your server, they never get access
to the source, only its output.
True! But what for the network technicians, system administrators and web
developers (to be very paranoid) that
--- Video Populares et Optimates [EMAIL PROTECTED] wrote:
If you mean to protect your source from your users, that is the case
already. Unless someone can compromise your server, they never get
access to the source, only its output.
True! But what for the network technicians, system
On 25 Jun 2003 at 16:42, Dan Joseph wrote:
Store that file outside the docroot. That way there is no chance
they can
get it from the web site. I myself use an ini file that is no where
near the docroot, and use parse_ini_file() to load the DB
information in, and then I connect to it.
Hello,
Doug Essinger-Hileman [EMAIL PROTECTED] wrote:
On 25 Jun 2003 at 16:42, Dan Joseph wrote:
Store that file outside the docroot. That way there is no chance
they can
get it from the web site. I myself use an ini file that is no where
near the docroot, and use parse_ini_file()
For some people, putting information outside the docroot isn't possible,
especially when your site is hosted.
On thing you can also try (which is nowhere near the security of outside
the docroot) is to put ocnfig data (user, pass, etc...) inside it's own
php file that is included in outfiles.
On 30 Jun 2003 at 10:25, - Edwin - wrote:
[mysql_info}
I think you meant [mysql_info]? (Check the closing bracket.)
It is correct on the server. My fingers didn't type what my brain
told
them to for this email.
Notice that you need to do something like this: (based on your
example)
The INI file should be:
[mysql_info]
host=spore.org
uid=myuserid
passwd=mypassword
Also, you'll probably want to do:
$INI = parse_ini_file(/home/revref/mysql.ini);
Doug Essinger-Hileman wrote:
I am just beginning to use php and mysql together (I'm new to both).
I am having trouble getting
Doug Essinger-Hileman [EMAIL PROTECTED] wrote:
[snip]
This leads to the following output:
Warning: Error parsing /mydirectory/mysql.ini on line 4 in Unknown on
line 0 Array ( [host] = spore.org [uid] = myuserid [passwd] =
mypassword)
The error message still remains, though now the
On 30 Jun 2003 at 11:20, - Edwin - wrote:
Warning: Error parsing /mydirectory/mysql.ini on line 4 in Unknown
on line 0 Array ( [host] = spore.org [uid] = myuserid [passwd] =
mypassword)
The error message still remains, though now the test confirms that
mysql.ini is being parsed.
On Friday 27 June 2003 15:01, [EMAIL PROTECTED] wrote:
This is true for your own authentication but I mean how to connect to the
database using md5.
You can't. However starting with MySQL 4 you can connect using SSL encryption,
but that would only be of significance if connection is remote.
I'm not a security expert at all, but...
The short answer to your question is that if you have to ask how to make
your code secure, then chances are, you probably shouldn't be attempting it
at all... but then again, we all have to learn somewhere...
Do a google search, and read thousands of
Hello Justin or Anybody else
Store an MD5 of the password, that way you're comparing the two hashes,
not
two passwords... even if someone stumbles into your database, they'll
only
see the MD5'd password. A further step would be encryption, on which
you
will have to do a LOT of reading.
Hi,
Why rely on some access restriction when you don't have to? You
include code
using a filesystem path. There is no need for it to reside under
document root.
Yes, you can make it so that certain things are not served
directly by the Web
server, but why take the extra risk? You gain
Hi,
The only reason that I was so adamant about it was I had a 'heated'
discussion with a business associate who's server was compromised - and he
was, lets say, insistant that the fact that there were database
passwords in
a php file inside the webroot was the reason it was insecure. I
On Thursday 26 June 2003 16:22, Jeff Harris wrote:
http://www.php.net/md5
Set the column type of password to be a char(32). Then, pass the password
through md5 to mysql to store it. To verify it, pass the password through
md5 then compare it to what's in the database.
Or, to avoid problems
Hello everyone,
I am getting started on a project on PHP that requires very very high levels of
security. I cannot give you exact details but the basics is that it deals with credit
cards.
I want some advice and tips from experts on the following
The server will be Red Hat Linux 7.3
1) The
Hi,
2) I store the db password and login info in a database.inc.php
file. Is there any way I can prevent a person from getting the db
pass even after he gets this file?
Store that file outside the docroot. That way there is no chance they can
get it from the web site. I myself use
I am getting started on a project on PHP that requires very very high
levels of security. I cannot give you exact details but the basics is
that it deals with credit cards.
I want some advice and tips from experts on the following
The server will be Red Hat Linux 7.3
1) The site will have to
Dan:
2) I store the db password and login info in a database.inc.php
file. Is there any way I can prevent a person from getting the db
pass even after he gets this file?
Store that file outside the docroot. That way there is no chance they can
get it from the web site. I myself use an
2) I store the db password and login info in a database.inc.php file.
Is there any way I can prevent a person from getting the db pass even
after he gets this file?
Store that file outside the docroot. That way there is no chance they
can get it from the web site. I myself use an ini file
2) I store the db password and login info in a database.inc.php file.
Is there any way I can prevent a person from getting the db pass even
after he gets this file?
Store that file outside the docroot. That way there is no chance they
can get it from the web site. I myself use an ini
--- Mike Morton [EMAIL PROTECTED] wrote:
That is precisely my point - if the user has shell access of any
type you are compromised - but if they do not get server access -
how could they possibly get the dotabase.inc.php? If that is
called directly then it will be parsed, and as long as you
--- Mike Morton [EMAIL PROTECTED] wrote:
That is precisely my point - if the user has shell access of any
type you are compromised - but if they do not get server access -
how could they possibly get the dotabase.inc.php? If that is
called directly then it will be parsed, and as long as you
Why rely on some access restriction when you don't have to? You include
code using a filesystem path. There is no need for it to reside under
document root. Yes, you can make it so that certain things are not
served directly by the Web server, but why take the extra risk? You
gain nothing.
Ok :)
The only reason that I was so adamant about it was I had a 'heated'
discussion with a business associate who's server was compromised - and he
was, lets say, insistant that the fact that there were database passwords in
a php file inside the webroot was the reason it was insecure. I just
Maybe I am missing something totally obvious, but if the server is set up
to
properly parse php files - having configs outside of the doc root should not
make much of a security difference?
Is this a true statement or not? (of course we have to make the assumption
that server access has
And, you can add to this
Never trust data from the client...always filter it(I use an lib to do
that)!
Make sure register_globals is off or code accordingly.
Make sure that you're using SSL (https).
Also, (maybe not directly related though...) if possible, separate your web
server from your
I want to know recommendations securing GET | POST | SESSIONS or other data
in WebPages.
One site I may be developing for the local govt has the need to take and
receive data from a database and data will be past with GET | POST |
SESSIONS.
Any recommendations regarding this would be welcome.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Never trust data from the client...always filter it(I use an lib to do that)!
Make sure register_globals is off or code accordingly.
HTH!
~Paul
On Saturday 09 November 2002 01:12 am, Creighton Brown wrote:
I want to know recommendations securing GET
33 matches
Mail list logo
