Keskustelu: Nettisivujen teko: Foorumisofta

http://jjp.jouluserver.com/foorumi/
Tuli tuollainen väsättyä. Haluaisin siitä kriittistä palautetta ja bugi-ilmoituksia.

Asentamisen ja mukauttamisen (ulkoasun, kieliasetusten, tms.) on tarkoitus olla mahdollisimman helppoa. Tosin käyttöohjeet puuttuvat vielä.

Suomalaisessa päivämääräkäytännössä ei tule välilyöntiä päivien, kuukausien ja vuoden väliin.

Korjattu, kiitos huomautuksesta.

Minun mielestä viestin kirjoittaminen pitäsi olla estetty, jos käyttäjä ei ole kirjautunut sisään.

Mitä järkeä on, että käyttäjä voi kirjoittaa viestin ja sen jälkeen painaa send message nappia, vain saadakseen viestin: please login.

Siistiä jälkeä muttei toki täydellistä. Tässä on muutama huomio:

• BIGINT ei ole oikea tyyppi aikaleimalle. Käytä tyyppiä TIMESTAMP tai DATETIME.
• TEXT ei ole oikea tyyppi IP-osoitteelle. IPv4-osoitteen voi tallentaa 32-bittisenä kokonaislukuna (INT; muunnos funktiolla INET_ATON).
• Viittaat alueisiin nimen perustella, mikä ei ole käytännöllistä eikä tehokasta. Joka taulussa pitäisi olla id.
• Nimeäminen saisi olla yhtenäisempää. Miksi joissain tauluissa on id mutta käyttäjätaulussa userid?
• Salasanat pitäisi ehdottomasti suolata! Muuten joku voi saada käsiinsä MD5-hashin ja selvittää siitä salasanan kokeilemalla tai hakemalla taulukosta. (MD5 omasta salasanastasi: fe8a...bbdf.)
• SQL-injektiot kannattaa estää, kuten tuolla käyttäjäsivuilla taitaa nykyään lukea.

style.php on luettavissa jos osaa lukea lähdekoodia.

Ariel => Korjattu.
Jokotai => ?
Metabolix =>
Miten ne voi estää? Entä mistä sait selville kenttien tyypit? Ja IP-osoitteiden pitäisi olla näkyvillä ainoastaan ylläpitäjille.
id-kenttä on yleensä tarkoittanut samaa kuin topic id, userid on käyttäjän id ja number on viestin id. Voihan nekin toki muuttaa, jos on tarvetta.

Laita kyselyssä kaikkien käyttäjän syötteiden ympärille hipsut. Muuten käy näin.

Jos noita nimiä ei tietäisi, niitä ei varmasti mistään arvaisi. Loogisempaa olisi laittaa joka tauluun id-kenttä ja viitata esimerkiksi message-taulusta topic-tauluun kentällä topic_id.

Nyt pitäisi olla kaikkien ympärillä, kokeiles vielä.

Ja muista ongelmista;

Metabolix kirjoitti:

Viittaat alueisiin nimen perustella, mikä ei ole käytännöllistä eikä tehokasta. Joka taulussa pitäisi olla id.

Alueilla on sekä varsinainen nimi, että tuo erikoismerkkejä hyväksymätön id-merkkijono. Itse pidän tätä parempana ratkaisuna, koska id-merkkijono ei muutu, vaikka aluetta siirreltäisiin. Ylläpitäjillä on oikeus muokata alueita editsections.php:llä, jolla alueita voi listätä, poistaa, siirtää ylös ja alas sekä vaihtaa nimeä ja id-merkkijonoa.

Metabolix kirjoitti:

Salasanat pitäisi ehdottomasti suolata! Muuten joku voi saada käsiinsä MD5-hashin ja selvittää siitä salasanan kokeilemalla tai hakemalla taulukosta. (MD5 omasta salasanastasi: fe8a...bbdf.)

Ömh?

Niitä muita korjailen sitten jossain vaiheessa.

Eikös muuten kaksinkertainen md5:nen ole jo huomattavasti turvallisempi.

jo123: mitä tarkoitat kaksinkertaisella?

tarkoitatko kenties md5( md5($foobar ) );

Onko haluttu ominaisuus, että ilman kirjautumista voi katsoa toisten käyttäjien profiili sivuja?

http://jjp.jouluserver.com/foorumi/profile.php?id=1

Eli id arvoa muuttamalla näkee kaikkien käyttäjien tiedot, vaikka ei edes olla kirjauduttu sisään.

Lebe80 kirjoitti:

jo123: mitä tarkoitat kaksinkertaisella?

tarkoitatko kenties md5( md5($foobar ) );

Kyllä tarkoitan.

jo123 kirjoitti:

Lebe80 kirjoitti:

jo123: mitä tarkoitat kaksinkertaisella?

tarkoitatko kenties md5( md5($foobar ) );

Kyllä tarkoitan.

Ei paranna tietoturvaa vaan vähentää sitä...

No kommenttini epäselväksi jäätyä annampa selvityksen. Pääsin eilen lukemaan style.php:n laittamalla osoite kenttään http://jjp.jouluserver.com/foorumi/style.php ja se ei ole kovin suotavaa jos joku haluaa tehdä tuhmiansa.

Jokotai: Tuolla näkyy ainoastaan CSS-koodia, josta on yhtä paljon iloa kuin sivun HTML-koodista. Vai mitä ajattelit, että sillä voisi tehdä?

Jokotai kirjoitti:

Pääsin eilen lukemaan style.php:n laittamalla osoite kenttään http://jjp.jouluserver.com/foorumi/style.php ja se ei ole kovin suotavaa jos joku haluaa tehdä tuhmiansa.

Pakkohan sen selaimenkin on päästä se lukemaan, joten silloin sinäkin pääset laittamalla sen osoitekenttään. Ainut vain, että tuossa generoidaan CSS-koodi PHP:llä.

Kaupallisissa ohjelmissa se on piilotettu lukemattomiin jottei joku vie vaivalla koodattuja sivun osia. Tietenkin selain voi lukea sen senkin jälkeen.

Jokotai kirjoitti:

Tietenkin selain voi lukea sen senkin jälkeen.

Miten?

Selaimen annetaan lukea koodi, mutta koodi ei ole ihmisten luettavissa.

Kerroppas nyt Jokotai joku kaupallinen softa missä noin on tehty?

Jokotai kirjoitti:

Selaimen annetaan lukea koodi, mutta koodi ei ole ihmisten luettavissa.

... ja milläs se ihminen siellä sivulla surffaa?

Ei tiedostoja voi piilottaa pelkästään ihmiseltä – varsinkaan, kun esimerkiksi Firebug näyttää pyytämättäkin kaikki selaimen lähettämät pyynnöt vastauksineen sekä kaikkien sivun elementtien todelliset tyylit jopa dynaamisten muutosten jälkeen ja vielä siistii CSS-koodin helppolukuiseen muotoon. (Etpä taida olla kovin hyvin perillä tietokoneiden toiminnasta.)

Ikinä ei pidä myöntää tehneensä virhettä:)

style.php hakee tietokannasta muutamia ylläpitäjien muokattavissa olevia tietoja, kuten logon urlin.

Juu vilkaisin nopeasti ja #user pisti silmään. Vilkaisin tarkemmin eikä se sitten ollutkaan mitään kovin vakavaa jos vakavaa ollenkaan.

Jokotai kirjoitti:

Juu vilkaisin nopeasti ja #user pisti silmään. Vilkaisin tarkemmin eikä se sitten ollutkaan mitään kovin vakavaa jos vakavaa ollenkaan.

Että ylipäänsä alat epäilemään tälläisen asian vakavuutta et voi olla kovinkaan asiantuteva.

Pistin sorsat ladattavaksi tänne näin; lisää palautetta kiitos.

Aikamoisia SQL-injektion mahdollisuuksia. Muista: älä ikinä luota käyttäjältä tulevaan dataan (ks. https://www.php.net/mysql_real_escape_string)!

Tein tällaisen funktion:

<?php
function mysql_query2() {
	$f_q=func_get_arg(0);
	for($fi=1; $fi<count(func_get_args()); $fi++) {
		$farg = func_get_arg($fi);
		$f_q = str_replace("{{$fi}}",mysql_real_escape_string($farg),$f_q);
	}
	return mysql_query($f_q,$GLOBALS['yhteys']);
}
?>

Ja testiohjelma:

<?php
include("topinclude.php");

$kysely=mysql_query2("SELECT username FROM users WHERE userid = '{1}'",$_GET['user']);
echo mysql_result($kysely,0,'username');
?>

...antaa tämän tuloksen. Riittääkö?

Aika sekava tuo minusta on, mutta eiköhän sekin asiansa aja. Itse tekisin ihan vain näin (tai mieluummin käyttäisin PDO:ta):

<?php
$kysely = mysql_query(sprintf("SELECT username FROM users WHERE userid = '%s'",
                               mysql_real_escape_string($_GET['user'])));

Tosin testailujen perusteella Jouluserverillä taitaa olla magic quotes päällä.

Viestin lähetys ei ainenkaan toimi...

Sulkumerkki jäi pois kun tein yhden pikkumuutoksen; korjattu.

$_POST- ja $_GET-arvoissahan on jo valmiiksi korvattu '-merkit \':llä; tarvitseeko niitä ajaa mysql_real_escape_string:n läpi, vai riippuuko kenties palvelimesta?

Jos palvelimella on käytössä magic quotes -asetus, muuttujiin lisätään automaattisesti kenoviivat. Vaikutus ei ole kuitenkaan täysin sama kuin funktiolla mysql_real_escape_string, joka on tarkoitettu nimenomaan MySQL-tietokannan kanssa käytettäväksi.

Yksi ratkaisu on tarkistaa ensin, onko palvelimella käytössä magic quotes -asetus, ja poistaa tarvittaessa kenoviivat. Tämän jälkeen merkkijonossa ei ole kenoviivoja palvelimesta riippumatta, jolloin ne voi lisätä itse funktiolla mysql_real_escape_string.

Funktio get_magic_quotes_gpc tarkistaa, onko magic quotes -asetus käytössä, ja funktio stripslashes poistaa asetuksen tuottamat kenoviivat muuttujasta.

Juuri tuota funkkaria kaipailin, kiitoksia.

Ihan kivan näköinen, mutta siellä sun täällä on joitain kohtia jotka voitaisiin tehdä paljon helpommin:

<?php
// Esimerkki: topinclude.php rivi 155
$f_handle=strparamsparse("{$fi}",$farg,$f_handle);

"{$fi}" voidaan kirjoittaa pelkästään vaikka $fi. Aaltosulut ovat jokatapauksessa turhia.
Lisäksi joissain funktioissa otat muuttujaan $x jonkin arvon ja muunnat heti seuraavalla muuttujan $y arvoksi $x.

Kiitos huomautuksesta.

Nitpick: Pidemmissä merkkijonoissa aaltosulkusyntaksilla saavutetaan mm. selkeyttä ^{[citation needed]}. Tietyissä tilanteissa niitä on pakko käyttää (kts. alla).

EDIT: Linkki korjattu.

Annatko esimerkin jolloin muuttujien ympärillä on pakollista käyttää aaltosulkeita? Linkkisi ei toimi. Joillain PHP:n versioilla voi ehkä olla eroja, tällä mitä käytän ei tehdä eroja aaltosulkeissa tai ilman. Joissain se tosiaan tuo selkeyttä (käytän itsekkin muunmuassa taulukkotietojen tulostamiseen: "... {$taulu["tieto"]} ..."), mutta sekin toimii ilman.

Millä versiolla toimii noin manuaalista löytyvä esimerkki? Mulla heittää parse erroria, versio 5.3.1.

<?php

class Foo {
    public $bar = 'BAR';
    public $baz = array(1,2,3);
    public static $v = 'value';

    public function moo() {
        return 'MOO';
    }
}

$fruits = array('strawberry' => 'tasty', 'banana' => 'yellow');
$foo = new Foo();

// Eivät toimi
echo "$foo->moo()\n";
echo "$foo->baz[1]\n";
echo "$fruits['banana']\n";
echo "Foo::$v\n";

/*
 * Seuraava ei toimi, koska globaalissa näkyvyysalueessa
 * ei ole määritelty muuttujaa $value
 */
echo "{${Foo::$v}}\n";

// Toimivat
echo "{$foo->moo()}\n";
echo "{$foo->baz[1]}\n";
echo "{$fruits['banana']}\n";

?>

Macro: Miten olisi esimerkiksi tämä:

<?php
$tuhannet = 13;
echo "{$tuhannet}000";
$muuttuja = 1;
echo "{$muuttuja}['x']";

Voi nuo asiat tehdä ilman aaltosulkeitakin:

<?php
$tuhannet = 13;
echo $tuhannet . "000";
$muuttuja = 1;
echo $muuttuja . "['x']";

Aina voi käyttää pisteitä aaltosulkeiden sijasta, joskus aaltoisulkeiden kanssa on vain selkeämpää.

Kyllä, mutta vetosin siihen että aaltosulkeet eivät suinkaan ole pakollisia käyttää.

Ei niin olekaan.

http://jjp.jouluserver.com/foorumi.rar <= tuolla on ne korjatut sorsat, lisää kritiikkiäghhg