PEAK XOOPS - News in englishin japanese

Archive | RSS |
  
Poster : GIJOE on 2009-01-07 04:37:49 (17735 reads)

in englishin japanese
There are a lot of XOOPS modules or PHP applications with SQL Injection still.

Protector can protect some patterns of SQL Injections.
It is just "some" instead of "all".

That's because Protector cannot distinguish attacks and fair requests just by REQUEST layer.

A word of "UNION" will be posted as "UNI-ON".

Such modification in REQUEST layer must be non-sense.

Then, Protector should judge them by both REQUEST layer and DB layer.

anti-XSS:
(a) doubtful requests are found
(b) ob_start()
(c) compare requests and outputs

SQL Injection:
(1) doubtful requests are found
(2) override DB layer
(3) compare requests and SQLs


It is not easy to implement (3) because Protector have to parse SQLs.
However, (2) will be the most problem for XOOPS.

Because there are no way to override DB layer.
I will suggest DB layer modification can be overridden for all core teams in the next entry.


This idea is based on JM2. (four years ago!)
He is the real hero for XOOPS

0 comments

Poster : GIJOE on 2008-11-12 04:08:39 (13064 reads)

in englishin japanese
serialize()/unserialize()
var_export()/eval()

A) security

You may feel it is dangerous to use eval().
Of course, you should not unserialize requested text.
However, you cannot use unserialize() for requested text also.

B) speed

A script for verification.


#!/usr/local/bin/(php-cli binaries)
<?php

function getmicrotime()
{
        list($usec, $sec) = explode(" ",microtime());
        return ((float)$sec + (float)$usec);
}

function var_import( $data ) {
        eval( '$ret='.$data.';' ) ;
        return $ret ;
}

$data = ( big array ) ;

$time_start = getmicrotime();

for( $i = 0 ; $i < $_SERVER['argv'][1] ; $i ++ ) {
        $serialized_data = serialize( $data ) ;
        $restored_data = unserialize( $serialized_data ) ;
        $serialized_data = var_export( $data , true ) ;
        $restored_data = var_import( $serialized_data ) ;
}

$time_end = getmicrotime() ;
echo $time_end - $time_start , "sec. \n" ;
?>

# serialize_bench.sh 100 (blue)
0.0085771083831787sec.
# serialize_bench.sh 100 (red)
0.031355857849121sec.

serialize()/unserialize() is faster than var_export()/eval() 3-4 times.
This result is independent from PHP versions.

But you should check the absolutely value.
Serializations is not so costed processes.
Then, I can say this is a disregardable cost.

C) usability

var_export()/eval() sweeps it

var_export()/eval() is free from encoding troubles.
And you can edit serialized text as you like.

D) conclusion

This is a standard to select it.

serialize() : redundant data / a lot of arrays
var_export() : primary data / few arrays

E) digression

I will use var_export()/eval() in my works.
pico in my developping tree has been already modified it.

0 comments

Poster : GIJOE on 2008-11-11 18:28:10 (11029 reads)

in englishin japanese
We always use 'serialize()' as a built-in function to serialize arrays/objects.

But, the format made by serialize() is hard to use for multibyte environments.
This procedure:

 serialize() -> encoding translation -> unserialize() 

causes an error.

You may say ...
"As I don't translate any text, this discussion sounds non sense"

No.

MySQL >= 4.1 stores any text as UTF-8.
This means that your serialized text can be translated automatically by MySQL

(your_encoding) -> UTF-8 -> (your_encoding)


This might be a critical trouble for XOOPS session.

The I'm trying the other serialization by 'var_export()'.

var_export() outputs text like:

array(
  'index' => 'value' ,
)


This format is strong for automatical/manual encoding translations.
We can unserialize the data by eval().

I will discuss merits and demerits of using var_export(), tomorrow.

0 comments

Poster : GIJOE on 2008-10-08 15:32:43 (16078 reads)

in englishin japanese
I'm writing a CGI to install/update XOOPS cores/modules.
It means you will be free from "uploading/overwriting massive files via ftp" or "chmod some directories before installing".

There are too many shared web servers like:
PHP: apache module (run as apache/nobody)
CGI: suExec (run as the file's owner)
Such users must be lucky

But, I don't write the CGI by perl but bash, because perl can cause some errors depending on modules/environments.

These are Tips/Problems to write CGI by bash.

- echo HTTP response headers
Without HTTP headers, the CGI returns 500 error

- how to get requests
GET variables: parse $QUERY_STRING
POST variables: parse <stdin>
This is a sample of the parser.


	query="$QUERY_STRING&"
	until [ -z "$query" ] ; do
		k_v=${query%%&*}
		query=${query#*&}
		key=${k_v%%=*}
		value=${k_v#*=}
	done


- how to use associated arrays
We have to use para-assoc-arrays like:
REQUEST_(key)=(value)

- easy to create big holes...
We have to write the code very carefully.

- use severe "white list"
We don't have a method like htmlspecialchars()
Then we never get characters other than [a-zA-Z0-9._-].
All requests must be constructed with /^[a-zA-Z0-9._-]*$/


I produce the CGI in the next entry.
Just a moment.


Poster : GIJOE on 2008-09-12 17:23:54 (9866 reads)

in englishin japanese
I've supervised a translation of "Ajax Security" into Japanese.


original:
"Ajax Security"
Addison-Wesley
Billy Hoffman & Bryan Sullivan

This news has no values to be written in English, sorry.

0 comments

(1) 2 3 4 ... 6 »
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!