Aleksejs

Ja sistēma ir svarīga, tad tās izstrādē piedalās īpašs paranojas eksperts, nevis tikai DBA. Uzskatīt, ka produkcijas sistēmā tiek veidotas, mainītas un dzēstas funkcijas un procedūras (ka vispār tiek veiktas kādas nedokumentētas izmaiņas) bez iepriekšējas testēšanas vispirms izstrādes, tad testa un visbeidzot akcepta vidē ir ļoti nenopietni. Bet kā jau teica bubu - šī tēma ir par sesiju glabāšanas failos vai DB izvērtēšanu.

Lai samazinātu risku ir ieteicams sesiju datu manipulēšanai izveidot īpašu DB lietotāju, kuram būtu tikai tiesības izpildīt stingri noteiktas "stored" funkcijas un pilnīgi neko citu.

Tajā tēmā tika apskatītas divas metodes: 1) vienkāršākā - uz servera reizi X minūtēs tiek iedarbināts skripts, kas rupji runājot izpilda darbību: UPDATE character_table SET character_health = MIN(100, character_health + 1) WHERE character_health < 100 2) Sarežģītākā: Nevis visu laiku pa tukšo izpildam UPDATE, bet gan tikai, kad notiek kaut kāda darbība izpildam: UPDATE character_table SET character_health = MIN(100, character_health + DATE_DIFF(last_time_something_happened,now(),MINUTES)), last_time_something_happened = NOW() WHERE character_id = X

Palasi šo tēmu: http://php.lv/f/topic/11467-browser-based-spele/

Lietas, kas uzreiz ienāca prātā. Plusi glabāšanai bāzē: * Neglabājas failu sistēmā - tādēļ lielākoties atkrīt visas drošības problēmas, kas saistītas ar sesijas datu nolasīšanu caur failu sistēmu (kas ir iespējama slikti nokonfigurēta servera gadījumā). * DB ir piemērotāka sadalītai sistēmai - līdz ar to sesijas ir vienkāršāk padarāmas pieejamas vairākos fiziskos web-serveros vienlaicīgi slodzes dalīšanai * DB ir potenciāli ātrāka datu apmaiņai (te gan ir jāizvērtē, jo savienojuma nodibināšana un pārtraukšana prasa laiku) Mīnusi glabāšanai bāzē: * Jārūpējas par datu validāciju, lai nepieļautu DB līmeņa drošības pārkāpumus (SQL injekcijas, piemēram) * Atkarībā no realizācijas sanāk, ka zinot DB lietotāju un paroli ir iespējams daudz vienkāršāk iegūt _visu_ sesiju datus. (SELECT * FROM sesijas). Vieglāk pat nekā pie glabāšanas failu sistēmā.

Securing PHP Web Applications - Introduction to Exploit Testing

SELECT DISTINCT kolonna FROM tabula;

Labdien, Kemito! Lūk daži čata skriptu paraugi: http://net.tutsplus.com/tutorials/javascript-ajax/how-to-create-a-simple-web-based-chat-application/ http://anantgarg.com/2009/05/13/gmail-facebook-style-jquery-chat/ http://openwebim.org/demo.php

Viens no relatīvi vienkāršiem, bet pietiekami efektīviem variantiem. Pieņemsim, ka tā tabula saucas Personas. Šai tabulai web-aplikācijā izmantotajam DB lietotājam ļaujam darboties ar šo tabulu tikai izmantojot "Stored procedure" - MySQL gadījumā Stored Procedure var piešķirt tiesības izpildīt to ar izveidotāja tiesībām, līdz ar to lietotājam pa taisno izpildīt brīvi izvēlētus vaicājumus pret tabulu ir liegts, taču visas darbības, kas nepieciešamas, šis lietotājs var izdarīt. Visticamāk, ka web aplikācijai ir tikai jāvar ievietot datus DB, bet klienta personas datus tai nemaz nav jāvar nolasīt, līdz ar to piešķiram web-aplikācijas lietotājam tikai tās minimālās tiesības (tikai uz tām stored procedures), kuras ļauj ievietot klienta informāciju. Atkarībā no servera konfigurācijas, var DB tabulas šifrēt ar OS līdzekļiem, Failu sistēmas līdzekļiem, DBVS līdzekļiem. Laukus papildus var šifrēt ar DBVS līdzekļiem (piemēram, AES_ENCRYPT()) vai web-aplikācijas līdzekļiem. Izvēloties šifrēšanu, ir rūpīgi jāizdomā un jānotestē gadījumi, kad kāda no komponentēm nekorekti beidz darbu, jo dažādu šifrēšanas līdzekļu kombinācija var novest pie datu neatjaunojamības.

Airbus... Aber lūdzu: <?php echo <<< AIRBUS_4EWA function check_all(){ if(document.getElementById('l1').value.length * document.getElementById('l2').value.length * document.getElementById('l3').value.length * document.getElementById('l4').value.length){ document.getElementById('p1').style.display = ''; } else { document.getElementById('p1').style.display = 'none'; } } ... <input id="l1" name="lauks1" type="text" onchange="check_all()"> <input id="l2" name="lauks2" type="text" onchange="check_all()"> <input id="l3" name="lauks3" type="text" onchange="check_all()"> <input id="l4" name="lauks4" type="text" onchange="check_all()"> <input id="p1" name="poga1" type="button" style="display : none"> ... AIRBUS_4EWA; ?>

Piemēram, šitā: function check_all(){ if(document.getElementById('l1').value.length * document.getElementById('l2').value.length * document.getElementById('l3').value.length * document.getElementById('l4').value.length){ document.getElementById('p1').style.display = ''; } else { document.getElementById('p1').style.display = 'none'; } } ... <input id="l1" name="lauks1" type="text" onchange="check_all()"> <input id="l2" name="lauks2" type="text" onchange="check_all()"> <input id="l3" name="lauks3" type="text" onchange="check_all()"> <input id="l4" name="lauks4" type="text" onchange="check_all()"> <input id="p1" name="poga1" type="button" style="display : none"> ...

Kurā brīdī lauciņš skaitās aizpildīts? :)

No sitepoint.com forumā papildinātā: Scanit - Secure file upload in PHP web-applications Par ar failu uploadu saistītajām drošības problēmām un to, kā no tām pareizi izvairīties. Paldies, sitepoint dalībniekam EastCost.

Lūdzu, neraksti N-tās tēmas katrā iepējamajā vietā!

Masīva elements: $subclass['char_id'] neeksistē vai ir vienāds ar ''

Ross Anderson - Security Engineering viena no labākajām jelkad sarakstītajām grāmatām par drošību Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone - Handbook of Applied Cryptography viena no labākajām un pilnīgākajām grāmatām par kriptogrāfiju

Jā.

Log failam Print screen? Atver log failu un izlasi, kas tajā rakstīts. http://httpd.apache.org/docs/2.2/logs.html

Firewall... A kas apache log failā rakstīts? VArbūt ka te atrisināta problēma: http://www.appservnetwork.com/forum/index.php?topic=1958.0

Nu... Ar tām idejām ir tā... Nerealizēta ideja, protams, arī ir vērtība, taču, lai ideju realizētu ir ujujuj kā japacenšas, jānofinansē, jāatrod tirgus, jāizveido apkalpošanas infrastruktūra utt utjp :)

codez, jā protams. Mehatronika ir ļoti perspektīva nodarbe. Bet sāk darboties jau parasti vispirms hobija līmenī (it sevišķi tie, kam "maizes darbs" ir kas cits). Un tāds neformāls "show-and-tell" pasākums būtu ļoti svētīgs.

Uzreiz tā prātā nenāk citi varianti, taču šī varianta priekšrocība ir tā vienkāršums (un vienkāršums ir laba lieta priekš drošības) :)

Prayer !! augstāk/zemāk ir pārprotami jēdzieni šajā gadījumā :) doma ir tāda, ja Tev ir web direktorija: /export/home/prayer/public_www/ tad aizsargājamos failus jāizvieto ārpus web direktorijas, teiksim: /export/home/prayer/private_stuff/ Līdz ar to skripts: fails.php, kas atrodas web direktorijā, varēs piekļūt šiem failiem pēc relatīvā ceļa: ../private_stuff/private_file.dat vai absolūtā ceļa: /export/home/prayer/private_stuff/private_file.dat

Ā, un šis arī var palīdzēt: http://fritzing.org/

Vēl aizvien šī sāpe :(