Re: [PHP] Sending messages from php to C++ application via UDP socket
On 18 May 2011 18:03, shiplu shiplu@gmail.com wrote: Try to think a string is an array of bytes. Parse that array of bytes at C++ end. There should host to network and network to host data conversion function. Use them. -- Shiplu Mokadd.im Just to confirm Sniplu's comment really. For example (see http://unicode.org/faq/utf_bom.html#bom4) $s_Utf8Bom = chr(0xEF) . chr(0xBB) . chr(0xBF); This will build the UTF-8 Byte Order Mark. You can use http://uk.php.net/manual/en/function.pack.php to build a binary string comprised of different values based upon C types (int/long, signed/unsigned, chars, hex strings, floats/doubles, nulls, etc.) In essence, if you have a C struct that represents the data you need to send, then you should be able to compose a suitable string. If you already have an app that can talk to the media player, then use a tool like wireshark to monitor the communication. That, at least, will give you real world example of the data you need to send. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: session_start()
On 18 May 2011 19:15, Nazish naz...@jhu.edu wrote:
Hi everyone,
I recently uploaded my website files to a server. When I tried to log into
my website, I received these error messages:
*Warning*: session_start()
[function.session-starthttp://www.myparcoasis.com/function.session-start]:
Cannot send session cookie - headers already sent by (output started at
/home2/myparcoa/public_html/index.php:10) in *
/home2/myparcoa/public_html/includes/login_form.php* on line *33*
*Warning*: session_start()
[function.session-starthttp://www.myparcoasis.com/function.session-start]:
Cannot send session cache limiter - headers already sent (output started at
/home2/myparcoa/public_html/index.php:10) in *
/home2/myparcoa/public_html/includes/login_form.php* on line *33*
*Warning*: Cannot modify header information - headers already sent by
(output started at /home2/myparcoa/public_html/index.php:10) in*
/home2/myparcoa/public_html/includes/login_form.php* on line *36*
*
*
The website worked fine on the Apache localhost server (I could log in), so
I'm not sure what's wrong with the code which is creating the error on the
online server. Any ideas? I've highlighted the two error lines (31 34).
I'd appreciate any insight! Thnx!
!---
WHEN USER CLICKS 'ENTER' TO LOGIN
!
?php
$submit = ($_POST['submit']);
if ($submit) // If user clicks the 'ENTER' button to login
{
// Connect to server and select database
include (includes/mysql_connect.inc);
include (includes/connect_res_directory.php);
// define login variables
$login = mysql_real_escape_string($_POST['login']);
$password = mysql_real_escape_string($_POST['password']);
$check_login = mysql_query(SELECT * FROM unit_info
WHERE login = '$login'
AND password = '$password');
$data = mysql_fetch_assoc($check_login);
// Are all the fields filled?
if($login $password)
{
// If fields are entered, verify username and password in mysql
database
if (mysql_num_rows($check_login)) // If the login and password
exists
{
//Login
* session_start();*
$_SESSION ['login'] = $data['login'];
* header (Location: index_test.php); // webpage for correct
login*
exit;
}
else
{
// Invalid username/password
echo div class='alert'The username or password you entered is
incorrect./div;
}
}
else
echo div class='alert'Please enter all the fields!/div;
}
?
The session cookie must be sent prior to any output. Including, but
not limited to, comments, whitespace, HTML code, etc.
Even a blank line before the first ?php line will be enough to tell
the web server that all the headers have been sent and to start
sending data.
At that stage, the session cookie - which is sent as a header - cannot
be sent as all the headers have been sent.
Options.
1 - Use output buffering. This tells PHP to not output anything until
the end of the script. So echo's, print's, etc. don't send their data
directly. This allows out of order headers and body to be sent and the
server sorts it all out at the end. You can override output_buffering
at runtime, but if headers have been sent due to white space, it won't
help with the session cookie.
2 - Remove all white space. Personally, this is the route I would use.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP] Warning: session_start()
On 19 May 2011 at 10:20, Richard Quadling rquadl...@gmail.com wrote: On 18 May 2011 19:15, Nazish naz...@jhu.edu wrote: Hi everyone, !--- WHEN USER CLICKS 'ENTER' TO LOGIN ! ?php code, code, code. ? The session cookie must be sent prior to any output. Including, but not limited to, comments, whitespace, HTML code, etc. 2 - Remove all white space. Personally, this is the route I would use. For the sake of completeness, that is whitespace *outside* the ?php ? tags. tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: session_start()
On 19/05/11 10:37, Tim Streater wrote: On 19 May 2011 at 10:20, Richard Quadlingrquadl...@gmail.com wrote: On 18 May 2011 19:15, Nazishnaz...@jhu.edu wrote: Hi everyone, !--- WHEN USER CLICKS 'ENTER' TO LOGIN ! ?php code, code, code. ? The session cookie must be sent prior to any output. Including, but not limited to, comments, whitespace, HTML code, etc. 2 - Remove all white space. Personally, this is the route I would use. For the sake of completeness, that is whitespace *outside* the?php ? tags. tim The comment should really be inside the php block: ?php /* WHEN USER CLICKS 'ENTER' TO LOGIN */ ... code ... ? otherwise (notwithstanding the session_start() problem) you'll get the comments in you HTML source - probably not what you wanted... -- Peter Ford, Developer phone: 01580 89 fax: 01580 893399 Justcroft International Ltd. www.justcroft.com Justcroft House, High Street, Staplehurst, Kent TN12 0AH United Kingdom Registered in England and Wales: 2297906 Registered office: Stag Gates House, 63/64 The Avenue, Southampton SO17 1XS -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Filtering data not with mysql...
Hi Richard, Oh my... I hate those pdf's :-(( Could someone tell me in some words what do I need to do beside mysql_real_escape_string() and Html input sanitizing? Thanks and sorry for the inconvenience) -- With best regards from Ukraine, Andre Skype: Francophile My blog: http://oire.org/menelion (mostly in Russian) Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion Original message From: ad...@buskirkgraphics.com ad...@buskirkgraphics.com To: 'Jason Pruim' Date created: , 4:17:55 AM Subject: [PHP] Filtering data not with mysql... To quote Jonathan Well, mysql_real_escape_string doesn't protect against sql injections more than addslashes, but that's not the reason you use it. addslashes() was from the developers of PHP whereas mysql_real_escape_string uses the underlying MySQL C++ API (i.e. from the developers of MySQL). mysql_real_escape_string escapes EOF chars, quotes, backslashes, carriage returns, nulls, and line feeds. There is also the charset aspect. However, it is a common thought among a lot of PHP programmers (beginning and even more advanced) that SQL injections are the only thing to guard against with sanitizing user input using it in a query. That, actually, is incorrect. If you only rely on *_escape_string and addslashes because you are only thinking about injections, you leave yourself vulnerable to attacks from users. http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf It's a nice read, especially if you like reading articles about PHP programming (*guilty*). Scroll down to page 78 where they talk about LIKE attacks. Richard L. Buskirk -Original Message- From: Jason Pruim [mailto:li...@pruimphotography.com] Sent: Wednesday, May 18, 2011 9:19 PM To: php-general@lists.php.net Subject: [PHP] Filtering data not with mysql... Hey Everyone, Probably a simple question but I wanted to make sure I was right before I got to far ahead of my self I have a form that I am working on and this form will be emailed to the recipient for processing (Not stored in a database). When I store in a database, I simply run all the data through mysql_real_escape_string() and it's all good... Without the database, is it just as easy as addslashes($var)? or is there more that needs to be done? In the end, the info will be echoed back out to the user to be viewed but not edited and emailed to someone to add the registration collect money, etc etc. Am I on the right track or do I need to rethink my whole process? :) Thanks Everyone! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Warning: session_start()
-Original Message- From: Pete Ford [mailto:p...@justcroft.com] Sent: 19 May 2011 11:36 To: php-general@lists.php.net Subject: Re: [PHP] Warning: session_start() On 18 May 2011 19:15, Nazishnaz...@jhu.edu wrote: Hi everyone, !-- - WHEN USER CLICKS 'ENTER' TO LOGIN !-- -- ?php code, code, code. ? The comment should really be inside the php block: Not to mention that not all of that so-called comment is actually comment, due to the little-understood principle that every -- inside !-- -- flips between comment and renderable text, and counting your hyphens *very* carefully reveals that the WHEN USER message is liable to be treated as renderable text. It is good practice, for this reason, NEVER to use any double-hyphen combinations within an HTML comment - single ones are fine, but any other kind of usage such as the above should be studiously avoided. (Speaking as one bitten on the bum multiple times by badly-formatted HTML comments in a specialist bought-in system, which constantly threatened to ruin my carefully crafted CSS layouts!) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom Email: m.f...@leedsmet.ac.uk Tel: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
Re: [PHP] Warning: session_start()
On 19 May 2011 16:05, Nazish naz...@jhu.edu wrote: I didn't realize that connecting to the MySQL database involved sending a header: eg. mysql_connect($host, $user, $mysql_pass); It doesn't. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/iZdpBR -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: session_start()
On 19 May 2011 16:05, Nazish naz...@jhu.edu wrote:
Thanks for all your suggestions such as removing whitespace before the ?php
tag and commenting issues. I made those changes.
I didn't realize that connecting to the MySQL database involved sending a
header: eg. mysql_connect($host, $user, $mysql_pass);
Does this mean this mysql_connect statement should go before the html tag
- even though mysql_connect is part of my conditional statement for logging
in? (code is below)
I primarily solved the header problem on my login page with a simple
replacement.
I used this line: echo 'script
language=javascriptlocation.href=first_page.php/script';
Instead of: header (Location: first_page.php);
And the page redirected :)
However, I'm still experiencing issues with session_start() -- once the
user's login password has been verified, the session begins and their
session ID is saved as a variable -- this process takes place in the middle
of the code, after the header. I can't put this right at the beginning of
the code. In this case, from what I understand, I should use output
buffering?
Warning: session_start() [function.session-start]: Cannot send session cache
limiter - headers already sent (output started at
/home2/myparcoa/public_html/index.php:10) in
/home2/myparcoa/public_html/includes/login_form.php on line 32
Thanks again for the insights.
On Wed, May 18, 2011 at 2:54 PM, Andre Polykanine an...@oire.org wrote:
Hello Nazish,
Try to delete your HTML comments before the ?php starting tag. So
remove *anything* before ?php.
--
With best regards from Ukraine,
Andre
Skype: Francophile
My blog: http://oire.org/menelion (mostly in Russian)
Twitter: http://twitter.com/m_elensule
Facebook: http://facebook.com/menelion
Original message
From: Nazish naz...@jhu.edu
To: php-general@lists.php.net
Date created: , 9:15:37 PM
Subject: [PHP] Warning: session_start()
Hi everyone,
I recently uploaded my website files to a server. When I tried to log into
my website, I received these error messages:
*Warning*: session_start()
[function.session-starthttp://www.myparcoasis.com/function.session-start
]:
Cannot send session cookie - headers already sent by (output started at
/home2/myparcoa/public_html/index.php:10) in *
/home2/myparcoa/public_html/includes/login_form.php* on line *33*
*Warning*: session_start()
[function.session-starthttp://www.myparcoasis.com/function.session-start
]:
Cannot send session cache limiter - headers already sent (output started at
/home2/myparcoa/public_html/index.php:10) in *
/home2/myparcoa/public_html/includes/login_form.php* on line *33*
*Warning*: Cannot modify header information - headers already sent by
(output started at /home2/myparcoa/public_html/index.php:10) in*
/home2/myparcoa/public_html/includes/login_form.php* on line *36*
*
*
The website worked fine on the Apache localhost server (I could log in), so
I'm not sure what's wrong with the code which is creating the error on the
online server. Any ideas? I've highlighted the two error lines (31 34).
I'd appreciate any insight! Thnx!
!---
WHEN USER CLICKS 'ENTER' TO LOGIN
!
?php
$submit = ($_POST['submit']);
if ($submit) // If user clicks the 'ENTER' button to login
{
// Connect to server and select database
include (includes/mysql_connect.inc);
include (includes/connect_res_directory.php);
// define login variables
$login = mysql_real_escape_string($_POST['login']);
$password = mysql_real_escape_string($_POST['password']);
$check_login = mysql_query(SELECT * FROM unit_info
WHERE login = '$login'
AND password = '$password');
$data = mysql_fetch_assoc($check_login);
// Are all the fields filled?
if($login $password)
{
// If fields are entered, verify username and password in mysql
database
if (mysql_num_rows($check_login)) // If the login and password
exists
{
//Login
* session_start();*
$_SESSION ['login'] = $data['login'];
* header (Location: index_test.php); // webpage for correct
login*
exit;
}
else
{
// Invalid username/password
echo div class='alert'The username or password you entered is
incorrect./div;
}
}
else
echo div class='alert'Please enter all the fields!/div;
}
?
---The next line is the first line of the file.
?php
session_start();
?
-The previous line is the last line of the file.
Save the file as test.php
Run it.
Now remove the blank line and re-run it.
See?
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY :
[PHP] Re: A Review Request
On 05/18/2011 02:22 PM, tedd wrote: Hi gang: I am considering providing PHP code to the general public via my website This is my first attempt: http://sperling.com/php/authorization/ What do you people think? Cheers, tedd I have to agree about the braces, but at our ages that's not going to change :-) My suggestion would be to use syntax highlighting. Geshi is a very good one that supports lots of languages/syntaxes, but PHP's highlight_file() and highlight_string() do an adequate job. As the site grows and you have PHP, HTML, CSS, JS and maybe INI files and SQL, then Geshi would handle all of these. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: A Review Request
At 10:32 AM -0500 5/19/11, Shawn McKenzie wrote: On 05/18/2011 02:22 PM, tedd wrote: http://sperling.com/php/authorization/ What do you people think? I have to agree about the braces, but at our ages that's not going to change :-) My suggestion would be to use syntax highlighting. Geshi is a very good one that supports lots of languages/syntaxes, but PHP's highlight_file() and highlight_string() do an adequate job. As the site grows and you have PHP, HTML, CSS, JS and maybe INI files and SQL, then Geshi would handle all of these. -- Thanks! -Shawn -Shawn: I thought about that and even considered using syntaxthighter, but decided against it because of the amount of code it requires -- and what happens when JS is off? So, I wrote a simple routine to show the code I want in the way I want it. For example, the code that runs the demo is what is shown, but the header and footer is replaced to something simpler. Additionally, all code looks the same to me -- highlighting some syntax in PHP, but not in JavaScript looks strange to me. YMMV. Thanks for your review. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Filtering data not with mysql...
Andre,
I remember this exact question and I thought jonathan gave the best
answer.
He suggested the addcslashes function in combination with the
mysql_real_escape_string.
http://php.net/manual/en/function.addcslashes.php
This is a good read and the function was updated as recent as 5.2.5.
Please pay close attention to the name it is a C-like function not the normal
addslashes.
$sub = addcslashes(mysql_real_escape_string(%something_), %_);
He goes on to explain that mysql_real_escape_string and addslashes do NOT
protect against this next example.
$sub = mysql_real_escape_string(%something); // still %something
mysql_query(SELECT * FROM messages WHERE subject LIKE '{$sub}%');
And recommends the following.
$sub = addcslashes(mysql_real_escape_string(%something_), %_);
// $sub == \%something\_
mysql_query(SELECT * FROM messages WHERE subject LIKE '{$sub}%');
I understand you are not going to insert into a database at this time.
But you did state you are going to email the contents and I would take the same
precautions with user input fields.
Only a suggestion I hope this helps.
Richard L. Buskirk
-Original Message-
From: Andre Polykanine [mailto:an...@oire.org]
Sent: Thursday, May 19, 2011 7:38 AM
To: ad...@buskirkgraphics.com
Cc: 'Jason Pruim'; php-general@lists.php.net
Subject: Re: [PHP] Filtering data not with mysql...
Hi Richard,
Oh my... I hate those pdf's :-((
Could someone tell me in some words what do I need to do beside
mysql_real_escape_string() and Html input sanitizing?
Thanks and sorry for the inconvenience)
--
With best regards from Ukraine,
Andre
Skype: Francophile
My blog: http://oire.org/menelion (mostly in Russian)
Twitter: http://twitter.com/m_elensule
Facebook: http://facebook.com/menelion
Original message
From: ad...@buskirkgraphics.com ad...@buskirkgraphics.com
To: 'Jason Pruim'
Date created: , 4:17:55 AM
Subject: [PHP] Filtering data not with mysql...
To quote Jonathan
Well, mysql_real_escape_string doesn't protect against sql injections more
than addslashes, but that's not the reason you use it. addslashes() was from
the developers of PHP whereas mysql_real_escape_string uses the underlying
MySQL C++ API (i.e. from the developers of MySQL). mysql_real_escape_string
escapes EOF chars, quotes, backslashes, carriage returns, nulls, and line
feeds. There is also the charset aspect.
However, it is a common thought among a lot of PHP programmers (beginning
and even more advanced) that SQL injections are the only thing to guard
against with sanitizing user input using it in a query. That, actually, is
incorrect. If you only rely on *_escape_string and addslashes because you
are only thinking about injections, you leave yourself vulnerable to attacks
from users.
http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf
It's a nice read, especially if you like reading articles about PHP
programming (*guilty*). Scroll down to page 78 where they talk about LIKE
attacks.
Richard L. Buskirk
-Original Message-
From: Jason Pruim [mailto:li...@pruimphotography.com]
Sent: Wednesday, May 18, 2011 9:19 PM
To: php-general@lists.php.net
Subject: [PHP] Filtering data not with mysql...
Hey Everyone,
Probably a simple question but I wanted to make sure I was right
before I got to far ahead of my self
I have a form that I am working on and this form will be emailed to
the recipient for processing (Not stored in a database).
When I store in a database, I simply run all the data through
mysql_real_escape_string() and it's all good... Without the database,
is it just as easy as addslashes($var)? or is there more that needs to
be done?
In the end, the info will be echoed back out to the user to be viewed
but not edited and emailed to someone to add the registration collect
money, etc etc.
Am I on the right track or do I need to rethink my whole process? :)
Thanks Everyone!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Filtering data not with mysql...
At 2:38 PM +0300 5/19/11, Andre Polykanine wrote: Oh my... I hate those pdf's :-(( Could someone tell me in some words what do I need to do beside mysql_real_escape_string() and Html input sanitizing? Thanks and sorry for the inconvenience) Hi: Here is part of what I wrote for my PHP class -- perhaps it will help: There are two simple rules in handling data: Rule Number 1 is to filter input. What that means specifically is to make certain that the user input is EXACTLY what you expect. You can filter, scrub, inspect, compare, or replace whatever comes in with what you expect. You need to be aware of what can come from a user and be able to deal with that data safely. Rule Number 2 is to escape output. What that means specifically is to transform any given chunk of data to a format that is suitable for the output medium. For example, ANY output headed to the browser should have htmlentities () preformed on it. If the data is headed to a database, it should have a database-specific function called, such as mysql_real_escape_string(). If the data is going to be included within an URL (i.e., GET parameter), it needs to pass through the urlencode() function. If the data is headed to XML it should have some kind of XML function called to wrap it in a CDATA or a pre-defined data format. If the data is headed out to JavaScript, then you need json (i.e., json_encode, json_decode, and json_last_error). So, you really just have TWO considerations: Filter input; Escape output It matters because Evil People do exist, and they WILL find a way to cause damage to you, and even to others, if you fail to protect your data and code. Common hacks include executing SQL to damage databases, or adding JavaScript to deface web-sites or even adding JavaScript to use YOUR web-site in an attack upon another website. Here is a good starting point for some of the details of what to do and why: http://phpsec.org/ HTH's tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
I will try to respond to the original question. Note: this is constructive criticism, so i wont do much in terms of praising the good parts It works, its very primitive, in some ways its pretty insecure, for example it provides no session hijacking protection, it's not written with the better of standards in mind, for one if you do store your password in code, you shouldn't store your password in clear text, that way if say i was able to bypass php execution and dumped that file out, i would still not have a useable password, so use a hash. There is no timing out or attempt management, for example i can write a 5 line-long brute script that will just pound your script with user ids and passwords, you should make it at least somewhat difficult for me to do that ;) Also don't declare a bunch of needless variables for their one-time use, don't compare unsanitized strings with a binary unsafe operator, server variables contain link to current script, here are examples of what i mean: -$self = basename($_SERVER['SCRIPT_NAME']); +$self = $_SERVER['PHP_SELF']; -$submit = isset($_POST['submit']) ? $_POST['submit'] : null; -if($submit == 'Submit') +if($_POST) -$pw = 'pw'; // define your password here -$user_id = isset($_POST['user_id']) ? $_POST['user_id'] : null; -$password = isset($_POST['password']) ? $_POST['password'] : null; -if (($user_id == $id) AND ($password== $pw)) +$pw='1a91d62f7ca67399625a4368a6ab5d4a3baa6073'; //sha1 hash of the password: php -r echo sha1(\pw\); +if (@strcmp($id, $_POST['user_id']) == 0 strcmp($pw, sha1($_POST['password'])) == 0) -- Alex -- -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Wed, May 18, 2011 at 3:22 PM, tedd t...@sperling.com wrote: Hi gang: I am considering providing PHP code to the general public via my website This is my first attempt: http://sperling.com/php/authorization/ What do you people think? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Filtering data not with mysql...
For input sanitizing, and this will be helpful to anyone who writes code, listen to dan kaminsky's keynote at The Next Hope. He did a very good job at explaining the landscape of web programming and the essence of SQL injection and XSS, as well as proposed pretty neat ways to fix these. If you are writing the app from scratch, to prevent SQL injection, use Mysqli + prepared statements... or implement the base64 hack, or i am working on a library to simplify and secure mysql in php for some of my work, though it's got a few implementation quirks it does fail by default, it does not allow you to insecurely interpolate, and it does use prepared statements for everything, i am sharing it with anyone who wants to look at it... Anyways, here's a direct link: http://c2047862.cdn.cloudfiles.rackspacecloud.com/Friday%20Keynote%20-%20Dan%20Kaminsky.mp3 Enjoy, Alex -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Wed, May 18, 2011 at 9:18 PM, Jason Pruim li...@pruimphotography.comwrote: Hey Everyone, Probably a simple question but I wanted to make sure I was right before I got to far ahead of my self I have a form that I am working on and this form will be emailed to the recipient for processing (Not stored in a database). When I store in a database, I simply run all the data through mysql_real_escape_string() and it's all good... Without the database, is it just as easy as addslashes($var)? or is there more that needs to be done? In the end, the info will be echoed back out to the user to be viewed but not edited and emailed to someone to add the registration collect money, etc etc. Am I on the right track or do I need to rethink my whole process? :) Thanks Everyone! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
Hello Alex, Two (stupid?) questions: 1. Why PHP_SELF is better than SCRIPT_NAME? 2. Why strcmp() is better than just comparing? -- With best regards from Ukraine, Andre Skype: Francophile My blog: http://oire.org/menelion (mostly in Russian) Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion Original message From: Alex Nikitin niks...@gmail.com To: PHP General Date created: , 9:29:35 PM Subject: [PHP] A Review Request I will try to respond to the original question. Note: this is constructive criticism, so i wont do much in terms of praising the good parts It works, its very primitive, in some ways its pretty insecure, for example it provides no session hijacking protection, it's not written with the better of standards in mind, for one if you do store your password in code, you shouldn't store your password in clear text, that way if say i was able to bypass php execution and dumped that file out, i would still not have a useable password, so use a hash. There is no timing out or attempt management, for example i can write a 5 line-long brute script that will just pound your script with user ids and passwords, you should make it at least somewhat difficult for me to do that ;) Also don't declare a bunch of needless variables for their one-time use, don't compare unsanitized strings with a binary unsafe operator, server variables contain link to current script, here are examples of what i mean: -$self = basename($_SERVER['SCRIPT_NAME']); +$self = $_SERVER['PHP_SELF']; -$submit = isset($_POST['submit']) ? $_POST['submit'] : null; -if($submit == 'Submit') +if($_POST) -$pw = 'pw'; // define your password here -$user_id = isset($_POST['user_id']) ? $_POST['user_id'] : null; -$password = isset($_POST['password']) ? $_POST['password'] : null; -if (($user_id == $id) AND ($password== $pw)) +$pw='1a91d62f7ca67399625a4368a6ab5d4a3baa6073'; //sha1 hash of the password: php -r echo sha1(\pw\); +if (@strcmp($id, $_POST['user_id']) == 0 strcmp($pw, sha1($_POST['password'])) == 0) -- Alex -- -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Wed, May 18, 2011 at 3:22 PM, tedd t...@sperling.com wrote: Hi gang: I am considering providing PHP code to the general public via my website This is my first attempt: http://sperling.com/php/authorization/ What do you people think? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
On May 19, 2011, at 2:44 PM, Andre Polykanine wrote: Hello Alex, Two (stupid?) questions: 1. Why PHP_SELF is better than SCRIPT_NAME? 2. Why strcmp() is better than just comparing? -- With best regards from Ukraine, Andre Skype: Francophile My blog: http://oire.org/menelion (mostly in Russian) Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion No idea about the first, and I've never used strcmp() before for an equality check. If there is something I'm missing I would love to know. Regards, -Josh Joshua Kehn | josh.k...@gmail.com http://joshuakehn.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP intreprets trailing slashes incorrectly?
I have a script: http://www.perturb.org/index.php I accidentally put a trailing / on the url and it STILL loaded: http://www.perturb.org/index.php/ Is that a bug in URL interpretation? I've tried it on three servers and all seem to have the same behavior. All three were Apache on Linux, but different versions as far back as PHP 5.2.x. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP intreprets trailing slashes incorrectly?
2011/5/19 Scott Baker bak...@canbytel.com: I have a script: http://www.perturb.org/index.php I accidentally put a trailing / on the url and it STILL loaded: http://www.perturb.org/index.php/ Is that a bug in URL interpretation? I've tried it on three servers and all seem to have the same behavior. All three were Apache on Linux, but different versions as far back as PHP 5.2.x. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php This is not PHP related. This probably works because of Apaches support for mod_rewrite. ie, http://www.example.com/virtual_dir/script/option/?Foo=bar -- /my_script.php?Foo=bar -- ** Hans Åhlin Tel: +46761488019 icq: 275232967 http://www.kronan-net.com/ irc://irc.freenode.net:6667 - TheCoin ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
PHP_SELF requires no processing (i.e. there is no need to do basename())
strcmp is binary-safe, i prefer and recommend using string-safe comparison
functions for strings... here is an example of why:
$value = 0;
if($value==not zero) {
echo oopsie, how did this happen, lets see how this works with strcmp
(or === which i would advise);
if(strcmp($value, not zero) == 0) {
echo You wont see this;
} else {
echo Because strcmp works correctly;
}
}
you can also use the exact comparator ===, as it compares types, it would
work well as well. Infact if you dont need to determing anything about the
string, i would suggest using the === operator as it is significantly
faster:
timed: 0m0.724s
?php
for($i=0; $i=1000; $i++){
if(1 === submit) {
continue;
}
}
timed: 0m4.785s
?php
for($i=0; $i=1000; $i++){
if(strcmp(1, submit)==0) {
continue;
}
}
--
The trouble with programmers is that you can never tell what a programmer is
doing until it’s too late. ~Seymour Cray
On Thu, May 19, 2011 at 2:44 PM, Andre Polykanine an...@oire.org wrote:
Hello Alex,
Two (stupid?) questions:
1. Why PHP_SELF is better than SCRIPT_NAME?
2. Why strcmp() is better than just comparing?
--
With best regards from Ukraine,
Andre
Skype: Francophile
My blog: http://oire.org/menelion (mostly in Russian)
Twitter: http://twitter.com/m_elensule
Facebook: http://facebook.com/menelion
Original message
From: Alex Nikitin niks...@gmail.com
To: PHP General
Date created: , 9:29:35 PM
Subject: [PHP] A Review Request
I will try to respond to the original question.
Note: this is constructive criticism, so i wont do much in terms of
praising
the good parts
It works, its very primitive, in some ways its pretty insecure, for example
it provides no session hijacking protection, it's not written with the
better of standards in mind, for one if you do store your password in code,
you shouldn't store your password in clear text, that way if say i was able
to bypass php execution and dumped that file out, i would still not have a
useable password, so use a hash. There is no timing out or attempt
management, for example i can write a 5 line-long brute script that will
just pound your script with user ids and passwords, you should make it at
least somewhat difficult for me to do that ;)
Also don't declare a bunch of needless variables for their one-time use,
don't compare unsanitized strings with a binary unsafe operator, server
variables contain link to current script, here are examples of what i mean:
-$self = basename($_SERVER['SCRIPT_NAME']);
+$self = $_SERVER['PHP_SELF'];
-$submit = isset($_POST['submit']) ? $_POST['submit'] : null;
-if($submit == 'Submit')
+if($_POST)
-$pw = 'pw'; // define your password here
-$user_id = isset($_POST['user_id']) ? $_POST['user_id'] : null;
-$password = isset($_POST['password']) ? $_POST['password'] : null;
-if (($user_id == $id) AND ($password== $pw))
+$pw='1a91d62f7ca67399625a4368a6ab5d4a3baa6073'; //sha1 hash of the
password: php -r echo sha1(\pw\);
+if (@strcmp($id, $_POST['user_id']) == 0 strcmp($pw,
sha1($_POST['password'])) == 0)
-- Alex --
--
The trouble with programmers is that you can never tell what a programmer
is
doing until it’s too late. ~Seymour Cray
On Wed, May 18, 2011 at 3:22 PM, tedd t...@sperling.com wrote:
Hi gang:
I am considering providing PHP code to the general public via my website
This is my first attempt:
http://sperling.com/php/authorization/
What do you people think?
Cheers,
tedd
--
---
http://sperling.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
On May 19, 2011, at 3:16 PM, Alex Nikitin wrote:
PHP_SELF requires no processing (i.e. there is no need to do basename())
strcmp is binary-safe, i prefer and recommend using string-safe comparison
functions for strings... here is an example of why:
$value = 0;
if($value==not zero) {
echo oopsie, how did this happen, lets see how this works with strcmp
(or === which i would advise);
if(strcmp($value, not zero) == 0) {
echo You wont see this;
} else {
echo Because strcmp works correctly;
}
}
you can also use the exact comparator ===, as it compares types, it would
work well as well. Infact if you dont need to determing anything about the
string, i would suggest using the === operator as it is significantly
faster:
timed: 0m0.724s
?php
for($i=0; $i=1000; $i++){
if(1 === submit) {
continue;
}
}
timed: 0m4.785s
?php
for($i=0; $i=1000; $i++){
if(strcmp(1, submit)==0) {
continue;
}
}
--
The trouble with programmers is that you can never tell what a programmer is
doing until it’s too late. ~Seymour Cray
I almost exclusively use ===.
Regards,
-Josh
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
=== or preg_match for me, lol, unless its all just math :)
--
The trouble with programmers is that you can never tell what a programmer is
doing until it’s too late. ~Seymour Cray
On Thu, May 19, 2011 at 3:26 PM, Joshua Kehn josh.k...@gmail.com wrote:
On May 19, 2011, at 3:16 PM, Alex Nikitin wrote:
PHP_SELF requires no processing (i.e. there is no need to do basename())
strcmp is binary-safe, i prefer and recommend using string-safe
comparison
functions for strings... here is an example of why:
$value = 0;
if($value==not zero) {
echo oopsie, how did this happen, lets see how this works with strcmp
(or === which i would advise);
if(strcmp($value, not zero) == 0) {
echo You wont see this;
} else {
echo Because strcmp works correctly;
}
}
you can also use the exact comparator ===, as it compares types, it would
work well as well. Infact if you dont need to determing anything about
the
string, i would suggest using the === operator as it is significantly
faster:
timed: 0m0.724s
?php
for($i=0; $i=1000; $i++){
if(1 === submit) {
continue;
}
}
timed: 0m4.785s
?php
for($i=0; $i=1000; $i++){
if(strcmp(1, submit)==0) {
continue;
}
}
--
The trouble with programmers is that you can never tell what a programmer
is
doing until it’s too late. ~Seymour Cray
I almost exclusively use ===.
Regards,
-Josh
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
[PHP] Warning: Cannot modify header information - headers already sent by - classic
Hi folks,
I'm running some code locally which should produce this fun error we
all know and love: Warning: Cannot modify header information -
headers already sent by... but does not. Switching from 5.3 to 5.2
reveals the error and running it on another server with 5.2 also shows
the error. I don't believe the version has anything to do with it,
but who knows. I set error_reporting = E_ALL | E_STRICT and verified
that display_errors = On, still nothing. Any ideas what could be
allowing a header('Location:'); call to redirect without throwing an
error after output has been sent to the browser?
Marc
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: Cannot modify header information - headers already sent by - classic
Hi
Header just be modified if its at the start of your script...
right code:
?php
...
header();
...
?
and not..
?php
...
?
php
header();
?
Valentine
On Thu, May 19, 2011 at 9:45 PM, Marc Guay marc.g...@gmail.com wrote:
Hi folks,
I'm running some code locally which should produce this fun error we
all know and love: Warning: Cannot modify header information -
headers already sent by... but does not. Switching from 5.3 to 5.2
reveals the error and running it on another server with 5.2 also shows
the error. I don't believe the version has anything to do with it,
but who knows. I set error_reporting = E_ALL | E_STRICT and verified
that display_errors = On, still nothing. Any ideas what could be
allowing a header('Location:'); call to redirect without throwing an
error after output has been sent to the browser?
Marc
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: Cannot modify header information - headers already sent by - classic
Thank you Balint but if you read my message I have a good understanding of what causes this error. My confusion is why it is not being thrown in this partciular instance. Marc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: Cannot modify header information - headers already sent by - classic
Sorry, I forgot the alternative.. You can use simply meta refresh
which is working anyway.
Usually I insert more than one redirector function to my script...
Eg.:
...
$back = $_SERVER['PHP_SELF'] . '?action=login';
//header('Location: '.$back.'');
echo 'meta http-equiv=refresh content=0;url='.$back.' /';
...
Valentine
2011/5/19 Bálint Horváth hbal...@gmail.com
Hi
Header just be modified if its at the start of your script...
right code:
?php
...
header();
...
?
and not..
?php
...
?
php
header();
?
Valentine
On Thu, May 19, 2011 at 9:45 PM, Marc Guay marc.g...@gmail.com wrote:
Hi folks,
I'm running some code locally which should produce this fun error we
all know and love: Warning: Cannot modify header information -
headers already sent by... but does not. Switching from 5.3 to 5.2
reveals the error and running it on another server with 5.2 also shows
the error. I don't believe the version has anything to do with it,
but who knows. I set error_reporting = E_ALL | E_STRICT and verified
that display_errors = On, still nothing. Any ideas what could be
allowing a header('Location:'); call to redirect without throwing an
error after output has been sent to the browser?
Marc
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sending messages from php to C++ application via UDP socket
On Thu, May 19, 2011 at 3:14 PM, Richard Quadling rquadl...@gmail.comwrote: On 18 May 2011 18:03, shiplu shiplu@gmail.com wrote: Try to think a string is an array of bytes. Parse that array of bytes at C++ end. There should host to network and network to host data conversion function. Use them. -- Shiplu Mokadd.im Just to confirm Sniplu's comment really. For example (see http://unicode.org/faq/utf_bom.html#bom4) $s_Utf8Bom = chr(0xEF) . chr(0xBB) . chr(0xBF); This will build the UTF-8 Byte Order Mark. You can use http://uk.php.net/manual/en/function.pack.php to build a binary string comprised of different values based upon C types (int/long, signed/unsigned, chars, hex strings, floats/doubles, nulls, etc.) In essence, if you have a C struct that represents the data you need to send, then you should be able to compose a suitable string. If you already have an app that can talk to the media player, then use a tool like wireshark to monitor the communication. That, at least, will give you real world example of the data you need to send. Richard. If there is already a protocol defined for such communication, use it. To get hint about this protocol use wireshark like tools. If no protocol is defined yet. You need to define one. For this all you have to make a serializer and an unserializer function for both php and c++ end that obeys the protocol. Now this serializer can use xml, yml, json, binary, base64 or any different format.. -- Shiplu Mokadd.im My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu Innovation distinguishes between follower and leader
Re: [PHP] Warning: Cannot modify header information - headers already sent by - classic
See if output_buffering and output_handler are set the same in your php.ini and/or phpinfo() output between working and non-working versions. Thanks Daniel. With output_buffering On the error was not displayed and the re-location fired, while Off caused it to display the error and continue loading the page. Marc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP intreprets trailing slashes incorrectly?
On Thu, May 19, 2011 at 15:04, Scott Baker bak...@canbytel.com wrote: I have a script: http://www.perturb.org/index.php I accidentally put a trailing / on the url and it STILL loaded: http://www.perturb.org/index.php/ Is that a bug in URL interpretation? I've tried it on three servers and all seem to have the same behavior. All three were Apache on Linux, but different versions as far back as PHP 5.2.x. It's not only intentional, it's also an exploitable feature used in search engine-friendly URLs and such, and is used by frameworks including CodeIgniter. You can grab that data from the $_SERVER['PATH_INFO'] superglobal value. Try this: ?php // Filename: test.php var_dump($_SERVER['PATH_INFO']); ? Then, if that file is in the web root of your local machine, hit it like so: http://localhost/test.php/this/is/neat http://localhost/test.php/another/fine/day/in/the/suburbs http://localhost/test.php/ http://localhost/test.php http://localhost/test.php/check/this/out?foo=barfruit[]=applefruit[]=bananafruit[]=cherry This way, you can see a variety of examples of how it grabs that and only that. Now get creative. ;-P -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Warning: Cannot modify header information - headers already sent by - classic
On Thu, May 19, 2011 at 15:45, Marc Guay marc.g...@gmail.com wrote:
Hi folks,
I'm running some code locally which should produce this fun error we
all know and love: Warning: Cannot modify header information -
headers already sent by... but does not. Switching from 5.3 to 5.2
reveals the error and running it on another server with 5.2 also shows
the error. I don't believe the version has anything to do with it,
but who knows. I set error_reporting = E_ALL | E_STRICT and verified
that display_errors = On, still nothing. Any ideas what could be
allowing a header('Location:'); call to redirect without throwing an
error after output has been sent to the browser?
See if output_buffering and output_handler are set the same in
your php.ini and/or phpinfo() output between working and non-working
versions.
More info on these can be found here:
http://php.net/manual/en/outcontrol.configuration.php
--
/Daniel P. Brown
Network Infrastructure Manager
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
Hi Alex,
Some nice conversation points, indeed. I do have a few follow-ups below:
On Thu, May 19, 2011 at 3:16 PM, Alex Nikitin niks...@gmail.com wrote:
PHP_SELF requires no processing (i.e. there is no need to do basename())
Actually, the way Tedd is using the info, PHP_SELF would potentially be
unsafe (unless it's been updated to correct for this type of issue (you'll
see the blog post has it's own security issues with some missing plugins):
http://www.mc2design.com/blog/php_self-safe-alternatives
So, it would require processing either where Tedd performed the processing
-OR- at in the markup to properly escape it.
strcmp is binary-safe, i prefer and recommend using string-safe comparison
functions for strings... here is an example of why:
$value = 0;
if($value==not zero) {
echo oopsie, how did this happen, lets see how this works with strcmp
(or === which i would advise);
if(strcmp($value, not zero) == 0) {
echo You wont see this;
} else {
echo Because strcmp works correctly;
}
}
This, in general, is a sound practice, although I would certainly advocate
the use of === as opposed to strcmp for performance reasons (as you pointed
out.)
To be fair to Tedd's code, though, I don't believe this would be an issue,
as I believe that the global arrays store the values as strings, so for
example:
$value = $_GET['test_value'];
if($value == not zero) {
echo oopsie, how did this happen, lets see how this works with strcmp
(or === which i would advise);
if(strcmp($value, not zero) == 0) {
echo You wont see this;
} else {
echo Because strcmp works correctly;
}
} else {
echo Even if you enter a 0, I'll bet you see me.;
}
You did make several other great points (session hijacking, multiple login
attempts), but to be fair to Tedd, there are many levels of security, and I
doubt he's trying to educate PHP developers with your background. In the
same way that someone's first foray into the world of database access using
PHP likely avoids a 20 table database with complex transactions for atomic
operations and in-memory queues for eventually consistent data where
performance is a must, I see this as a reasonable first exposure to the
general principles of how one might use the features of PHP to password
protect a group of pages in a site.
There are some forms of data I'd protect with an authentication scheme of
this simplicity (maybe I just have a mileage app that I'm using to keep
track of my weekly running, or maybe my wife has a todo list that she
manages, etc.) However, as you pointed out, the code wouldn't merit use in
situations where a higher security level is desired. Even your changes have
security issues:
- You're using a weak hash protocol, and not using a salt:
https://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storage
https://www.owasp.org/index.php/OWASP_Top_10_Threats_and_Mitigations_Exam
- You don't mention using HTTPS, and session fixation, even if you use
other techniques (session_regenerate_id after changing auth level, etc.)
can't be prevented without this (let alone protecting the passwords from a
man in the middle attack.)
For developers who are first starting to think about a basic form of
authentication, the code is a nice start. Perhaps Tedd could point out the
shortcomings and provide some follow-up examples that provide progressively
higher levels of security. That would be a nice, and I'm sure those on the
list with your background would help on provide feedback on the more complex
examples that progressively help new developers achieve higher levels of
security.
That said, you made some really nice points, and I'm hopeful Tedd considers
them carefully. His site is a nice resource for many PHP developers already
(especially those just starting out), and these changes can only make it
better.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
Re: [PHP] A Review Request
At 2:29 PM -0400 5/19/11, Alex Nikitin wrote: I will try to respond to the original question. Note: this is constructive criticism, so i wont do much in terms of praising the good parts It works, its very primitive, in some ways its pretty insecure, for example it provides no session hijacking protection, it's not written with the better of standards in mind, for one if you do store your password in code, you shouldn't store your password in clear text, that way if say i was able to bypass php execution and dumped that file out, i would still not have a useable password, so use a hash. There is no timing out or attempt management, for example i can write a 5 line-long brute script that will just pound your script with user ids and passwords, you should make it at least somewhat difficult for me to do that ;) I agree if I was creating a more secure script. I have scripts where the user enters a user id and password and the password is immediately hashed and stored in a database. The next time in, the user's input password is hashed again and compared with the stored encrypted password. That way the raw password is never stored anywhere. I even have people who ask me Look at your records and tell me what's my password? and I say that I can't answer them because the data has been one-way hashed. Instead, I have them use the forgot password routines. I also have a script that monitors how many times a user (via their IP) tries to log on and restricts those attempts to a certain number of times within a time limit. As for XXS, I'm not sure as to what the exposure is because I am not putting questionable data into the HTML document. Rather, the questionable data is compared to known data -- if there is a match then the user is allowed to continue -- if not, it fails. I don't use the user's data for anything other than that. If there is more to consider here, I would like to hear about it. In any event, for me to consider all those points and also make the demo simple enough for a novice user would be very difficult. I would like to introduce to the novice a way to protect their pages. But if I make it too complicated, then they simply won't understand. It is obvious that I should also tell the user that this is NOT the most secure way to make things private and that there are other security concerns. What say you? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
Hey Adam :) I devoted entire 3 minutes to glimpsing over the code and showing simple ways to fix them, you make excellent points, i simply didnt even look into them. You are absolutely correct in saying that sha1 a weak way to do this (though it is wy better then md5), ofcourse the propper way to go about this is a sha256 hash with a solid salt, however if the salt is stored in clear text in code, and it would have to be in this case, granted someone gets the said code, the having used the salt adds no security to the hash. The whole idea behind is to add a little bit more at each level, so for example on your typical php/database setup, salt may be stored in code while the hash is stored in mysql, having the hash from the database and not having the salt makes it nearly impossible to reverse the hash, but if you could get both the salt and hash out of the database or in our case the code, it is no more secure then a hash by itself. Hmm that is an interesting bit about php_self, while my implementations (while still using php_self) are not exploitable in this fashion, its still an interesting concept, no this has not been locked down, as far as i can see from a couple of tests just did (briefly). Hmm, i have to reconsider how i approach PHP_SELF now, i will have to wrap it in htmlentities or something, i'll ponder that for now... In the meanwhile, i think it would be interesting to bounce some of this code to have someone else look at it, especially security-wise, it's been a bit of a project of mine when i get a few mins, i had to do something about it for our Amazon boxes that use rds, as you cant just use b64d, because you cant add any mysql modules, so i came up with this idea, but i'm not 100% satisfied with it atm: http://pastebin.com/tK5tBuiU Yeah https was going to be my next suggestion, actually why i got back into email before heading home and possibly forgetting, however you have to make sure you set up the server to be decently secure with it too, disable weak crypto there, fix tls renegotiation, etc. To be honest, at least with session fixation, i didnt look at the secured page code at all, but yes, a very good suggestion, i usually make a point of making it when someone asks me to glimpse at their code that uses sessions too, bah, it's been a long day at work, lol. Also i figured that Tedd would hopefully start by addressing the first set of things i threw at him, and then we can progress into more and more secure solution :) Tedd, yes you do have to worry about xss, yes with unescaped PHP_SELF you can inject code into the form here form name=my_form action=?php echo($self);? method=post Also a bit of a pep talk. You can make your code a lot more secure with a little bit more work. It would be wrong to stop and not worry about security, simply because code splits into two categories, secure and owned, there is no grey area, if someone can bypass your security, then no matter how simple your code was, it did nothing to stop the attacker, and thus did not fulfil its primary duty, in today's web world some security is not any better then no security, protecting against regular users is pointless as they are not the ones who will try to break your system ;) Just my $.02 -- Alex The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Thu, May 19, 2011 at 8:18 PM, tedd tedd.sperl...@gmail.com wrote: At 2:29 PM -0400 5/19/11, Alex Nikitin wrote: I will try to respond to the original question. Note: this is constructive criticism, so i wont do much in terms of praising the good parts It works, its very primitive, in some ways its pretty insecure, for example it provides no session hijacking protection, it's not written with the better of standards in mind, for one if you do store your password in code, you shouldn't store your password in clear text, that way if say i was able to bypass php execution and dumped that file out, i would still not have a useable password, so use a hash. There is no timing out or attempt management, for example i can write a 5 line-long brute script that will just pound your script with user ids and passwords, you should make it at least somewhat difficult for me to do that ;) I agree if I was creating a more secure script. I have scripts where the user enters a user id and password and the password is immediately hashed and stored in a database. The next time in, the user's input password is hashed again and compared with the stored encrypted password. That way the raw password is never stored anywhere. I even have people who ask me Look at your records and tell me what's my password? and I say that I can't answer them because the data has been one-way hashed. Instead, I have them use the forgot password routines. I also have a script that monitors how many times a user (via their IP) tries to log on and restricts those attempts to a certain number
Re: [PHP] A Review Request
At 2:29 PM -0400 5/19/11, Alex Nikitin wrote: Also don't declare a bunch of needless variables for their one-time use, don't compare unsanitized strings with a binary unsafe operator, server variables contain link to current script, here are examples of what i mean: I object. First of all 'needless' is in the eye of the beholder. I've seen ton's of 'needless' comments about how programmers waste precious space by declaring needless variables because they can do things more cryptic. I've also heard in the past how programmers should be cryptic and even shorten their variable names, not use indenting, and do all sorts of other nonsense to save space and make their code run quicker. However, they forget a couple of important considerations. 1. Code running tomorrow will run-faster and cost-less to store than today. That's a fact and while we can argue, the argument becomes less important as time passes. If I don't win this argument today, I will win it tomorrow. 2. I also claim that if I can make my code more readable and easier to maintain by adding a 'needless variable now and then, then it's well worth the cost. And as I said before, that cost is reducing every day, while maintaining readable code is becoming more important. So again, I'll eventually win this argument. So, whenever you feel in the mood, create another 'needless variable' because they need love too! -$self = basename($_SERVER['SCRIPT_NAME']); +$self = $_SERVER['PHP_SELF']; They return different things. I want the name of the script. -- -$submit = isset($_POST['submit']) ? $_POST['submit'] : null; -if($submit == 'Submit') +if($_POST) if($_POST) what? I'm cleaning the the POST variable. If the user has not clicked Submit, then I don't want to evaluate the POST. Sure, there are ways to forge and pass a POST variable, but this is one step in cleaning a superglobal. - -$pw = 'pw'; // define your password here -$user_id = isset($_POST['user_id']) ? $_POST['user_id'] : null; -$password = isset($_POST['password']) ? $_POST['password'] : null; -if (($user_id == $id) AND ($password== $pw)) +$pw='1a91d62f7ca67399625a4368a6ab5d4a3baa6073'; //sha1 hash of the password: php -r echo sha1(\pw\); +if (@strcmp($id, $_POST['user_id']) == 0 strcmp($pw, sha1($_POST['password'])) == 0) Sure. Here's the problem -- where's the novice going to get the hash for the password? I don't want to force the novice into another step in this demo. Besides, the only way that an evil doer can see the code in text is *if* there is a problem with the server -- isn't that right? If that's the case, then there's more problems here than what the user could have planned for. However, if there is another way, please explain. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
At 8:51 PM -0400 5/19/11, Alex Nikitin wrote: Tedd, yes you do have to worry about xss, yes with unescaped PHP_SELF you can inject code into the form here form name=my_form action=?php echo($self);? method=post Ahhh! Most excellent. I'll change that. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Review Request
On Thu, May 19, 2011 at 8:51 PM, Alex Nikitin niks...@gmail.com wrote: Hey Adam :) I devoted entire 3 minutes to glimpsing over the code and showing simple ways to fix them, you make excellent points, i simply didnt even look into them. You are absolutely correct in saying that sha1 a weak way to do this (though it is wy better then md5), ofcourse the propper way to go about this is a sha256 hash with a solid salt, however if the salt is stored in clear text in code, and it would have to be in this case, granted someone gets the said code, the having used the salt adds no security to the hash. The whole idea behind is to add a little bit more at each level, so for example on your typical php/database setup, salt may be stored in code while the hash is stored in mysql, having the hash from the database and not having the salt makes it nearly impossible to reverse the hash, but if you could get both the salt and hash out of the database or in our case the code, it is no more secure then a hash by itself. Hmm that is an interesting bit about php_self, while my implementations (while still using php_self) are not exploitable in this fashion, its still an interesting concept, no this has not been locked down, as far as i can see from a couple of tests just did (briefly). Hmm, i have to reconsider how i approach PHP_SELF now, i will have to wrap it in htmlentities or something, i'll ponder that for now... In the meanwhile, i think it would be interesting to bounce some of this code to have someone else look at it, especially security-wise, it's been a bit of a project of mine when i get a few mins, i had to do something about it for our Amazon boxes that use rds, as you cant just use b64d, because you cant add any mysql modules, so i came up with this idea, but i'm not 100% satisfied with it atm: http://pastebin.com/tK5tBuiU Yeah https was going to be my next suggestion, actually why i got back into email before heading home and possibly forgetting, however you have to make sure you set up the server to be decently secure with it too, disable weak crypto there, fix tls renegotiation, etc. To be honest, at least with session fixation, i didnt look at the secured page code at all, but yes, a very good suggestion, i usually make a point of making it when someone asks me to glimpse at their code that uses sessions too, bah, it's been a long day at work, lol. Also i figured that Tedd would hopefully start by addressing the first set of things i threw at him, and then we can progress into more and more secure solution :) Tedd, yes you do have to worry about xss, yes with unescaped PHP_SELF you can inject code into the form here form name=my_form action=?php echo($self);? method=post Also a bit of a pep talk. You can make your code a lot more secure with a little bit more work. It would be wrong to stop and not worry about security, simply because code splits into two categories, secure and owned, there is no grey area, if someone can bypass your security, then no matter how simple your code was, it did nothing to stop the attacker, and thus did not fulfil its primary duty, in today's web world some security is not any better then no security, protecting against regular users is pointless as they are not the ones who will try to break your system ;) Just my $.02 All great points, Alex. In terms of your pastebin code, you have a succinct, clean coding style (Strunk White would be proud.) If I have some free time this weekend, I'll try to take a look, for whatever little that's worth :P Pleasure, Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] A Review Request
My general rule of thumb regarding variables from post and/or get, is such:
if you use it once, dont throw it into a variable, if you use it more than
once, then put it in a variable. If you name things consistently and well,
regardless of how long from now you are reading the code, $_POST['password']
will be just that, and it's not any less obscure then $pass, especially if
used just once, and cleaner...
Regardless of the cost of performance decreasing, performance is an overall
thing, if you dont care for performance in any one place, you don't really
care for performance, and in the instant world that we live in,
performance should be as serious of a consideration as security, that is
actually why Facebook wrote their PHP interpreter, they understand that
users want FAST. And performance means you should consider things, even
overly extensive commenting, even if something is better done one way,
doesnt mean it is the best way to do it. For example i LOVE recursive
functions, but i never write them in scripting languages, because they run a
lot slower then a for loop, however more elegant any such function would be,
it just doesn't perform... And i understand it's a simple example, those two
variables don't really matter, and wont use much more space, but constantly
thinking consistency, security, performance, will help you achieve better
code in the end, even if puristically-speaking it's worse.
Another reason is overall clarity and clenliness of the code, counting lines
is a bad practice, but avoiding unnecessary lines helps, and it adds up,
sometimes using inline logic and avoiding declaring unnecessary variables
goes a long way to make your code much more concise and readable actually,
especially if you have a lot of it. That said, i always initialize my
arrays, because it avoids notices...
but here is a brief example:
(!DEBUG) || error_log(Fetch Data: .memory_get_usage()/1048576);
reads and writes a lot better and faster then:
if(DEBUG) {
$memory = memory_get_usage()/1048576;
error_log(Fetch Data: .$memory);
}
if($_POST) is just that, that will check if someone/thing used POST to POST
data to your script. You don't post anything else, and you check for
existence of other variables, you are not any better with checking for
submit. And your browser will most certainly never send a post request just
for the kick of it, so... not sure what your objection to a cleaner if
statement is exactly..? (It's as easy to pass a submit as it is to pass a
username and a password, you dont gain any security by checking for submit)
You want the path of the script as well, if i put it in my test folder under
doc root, your action will never execute because it will be a level off.
$self=htmlentities($_SERVER['PHP_SELF']);
Servers occasionally mess up, and it can not even be their fault, php messes
up, stuff happens. If you use security in layers, then code with a hashed
password will not reveal your password, where as if i am able to dump your
source, i have the keys to your kingdom otherwise. And you comment and
document ways to get the hash, or provide a utility to generate that hash,
through say an install script or something that will fill in the password.
That code and the fact that apache should execute it, is currently your only
layer of security, so make it two...
Your scenario:
server messes up or i change htaccess to dump your code
i look at code
i own keys to your kingdom, and you dont know about it
My scenario:
server messes up
i look at code
i'm still SOL... no keys, so your protected area is still protected
--
The trouble with programmers is that you can never tell what a programmer is
doing until it’s too late. ~Seymour Cray
On Thu, May 19, 2011 at 8:57 PM, tedd tedd.sperl...@gmail.com wrote:
At 2:29 PM -0400 5/19/11, Alex Nikitin wrote:
Also don't declare a bunch of needless variables for their one-time use,
don't compare unsanitized strings with a binary unsafe operator, server
variables contain link to current script, here are examples of what i
mean:
I object.
First of all 'needless' is in the eye of the beholder. I've seen ton's of
'needless' comments about how programmers waste precious space by declaring
needless variables because they can do things more cryptic. I've also heard
in the past how programmers should be cryptic and even shorten their
variable names, not use indenting, and do all sorts of other nonsense to
save space and make their code run quicker.
However, they forget a couple of important considerations.
1. Code running tomorrow will run-faster and cost-less to store than today.
That's a fact and while we can argue, the argument becomes less important as
time passes. If I don't win this argument today, I will win it tomorrow.
2. I also claim that if I can make my code more readable and easier to
maintain by adding a 'needless variable now and then, then it's well worth
the cost. And as I said before, that cost is reducing
Re: [PHP] A Review Request
On Wed, May 18, 2011 at 03:22:35PM -0400, tedd wrote: Hi gang: I am considering providing PHP code to the general public via my website This is my first attempt: http://sperling.com/php/authorization/ What do you people think? I've always been a fan of your site(s). It's been annoying from time to time that the code making a certain example work wasn't available. Here, it is. As pointed out, there are security and other issues. But since I know what kind of code you can produce, I realize you left these issues in place because you were getting at a different point. And I agree with the majority that your bracing style is horrid. But I long ago despaired of turning you from the Dark Side(tm). ;-} Making professional coding techniques visible to others can only be a good thing. I've been doing this for a while, but I'm still interested in how other people do these things. I never know when I might learn something. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
