web

Drupal szavazatok és felhasználók összeköthetősége

Azt hiszem a következő kép mindent elmond arról, hogy mennyire köthetőek össze egy Drupal szavazás szavazatai az azt leadó felhasználókkal:

Képernyőmentés egy Drupal oldalról, amelyen egy szavazásnál a felhasználók által leadott szavazatok láthatóak felhasználónként listázva.

Szavazáskor érdemes észben tartani, hogy ez megőrződik az idők végezetéig, és valószínűleg ugyanez a helyzet az egyéb szavazós oldalak nagy részével is.

Nyilván, egy egyszerű webes szavazásnál a szerver mindenképp megtudja, hogy mire szavazott a felhasználó, hacsak nem hozunk össze mondjuk JavaScripttel egy teljes anonimitást biztosító szavazást, de ez nem túl jellemző. Mindenesetre jobban örülnék, ha a választott opciót nem a felhasználó nevéhez köthetően tárolná a Drupal (és bármelyik másik webes rendszer sem).

A szavazatok nem összeköthető tárolásához csak két táblára van szükség:

szavazott felhasználók:

  • szavazás azonosítója
  • felhasználó azonosítója

szavazások állása:

  • szavazás azonosítója
  • opció azonosítója
  • leadott szavazatok száma

Szavazáskor a szavazott felhasználók táblába bekerül egy rekord a felhasználó és a szavazás azonosítójával. Így meg lehet akadályozni, hogy egy ember kétszer szavazzon. A szavazatát külön nem rögzítjük, az csak a szavazások állása táblába kerül be, konkrétan a választott opció számlálóját (leadott szavazatok száma attribútum) növeljük eggyel.

A dolog hátránya, hogy nem lehet szavazatot visszavonni (és újra szavazni), csak a szavazás teljes újrakezdésével.

(Biztos vagyok benne, hogy nem én vagyok az első, aki a fenti dolgot leírja, viszont hirtelen nem találtam semmilyen más oldalt, ami ugyanerről a témáról szól. Kapcsolódó linkeket örömmel fogadnék akár kommentben, akár e-mailben.)

Technikai részletek: Drupal 6, beépített Poll modul.

Advanced blog.hu comment filter

A userscripts.org-on már van egy kommentszűrő a blog.hu-s blogokhoz (Blog.hu komment filter 1.1), de elég fapados, kézzel kell a szkriptbe beleszerkeszteni a szűrendő felhasználók azonosítóit. A szkript keresését felhasználva újraírtam a kódot, most már minden komment mellé kerül egy „Mute” link. Rákattintva a GM_setValue() hívással perzisztensen tárolódik a némított felhasználó ID-ja, illetve a kommentek is frissítésre kerülnek. Továbbá a „Mute” gomb is le lesz cserélve „Unmute”-re.

Eltüntetni csak a komment szövegét tüntetem el. A fejléc megmarad, oda kerül a „Unmute” link, valamint így látni lehet mennyire volt érdemes használni a szkriptet, hány kommenttől szabadultunk meg. Továbbá, ha egy nem tiltott kommentelő hivatkozik a „@név” szerkezettel egy korábbi kommentre, akkor a hivatkozott komment megjelenítése egyszerűen engedélyezhető. Az avatar eltüntetését már nem volt kedvem megoldani, de bárki megteheti, a szkript letölthető a userscripts.org-ról.

Csak óvatosan az új CA-kkal

Firefox alatt három kattintással importálható egy CA a többi gyári tanúsítvány mellé. Ez azonban elég kockázatos lehet.

Először is, ez közel sem ugyanaz, mint amikor egy saját maga (vagy akárki) által aláírt tanúsítvánnyal rendelkező https linket látogatunk meg, majd adjuk hozzá ezt a tanúsítványt kivételként a böngészőnk megfelelő listájához. A „kivétel hozzáadása” funkció használatakor az oldal által küldött tanúsítvány csak az adott oldalhoz lesz érvényes. Ha CA-t importálunk, akkor a CA bármilyen weblaphoz tartozó tanúsítványt aláírhat és azt a böngésző el is fogja fogadni.

Ezzel önmagában még nincs is probléma, egy teljes támadáshoz egy man-in-the-middle támadásra is szükség van. Ha importáltuk a támadó CA-ját, ő ezután készít egy új tanúsítványt a tamadottnetbank oldalhoz, aláírja a CA privát kulcsával, beállít egy SSL-es webszervert, majd MITM támadás segítségével átirányítja a böngészőnket az ő szerveréhez.

A támadó webszervere által adott tanúsítványt olyan CA által van aláírva, amit a böngészőnk ismer és megbízik benne. Ott lesz a lakat az alsó sorban, és vígan használhatjuk az oldalt.

További adalék, hogy nem is feltétlenül kell, hogy a támadó CA-ját importáljuk, elég ha csak egy gyengén védett CA privát kulcsát megszerzi a támadó. Érdemes ránézni mondjuk a NetLock vagy a Microsec weblapján lévő doksikra, hogy egy rendes, például Mozilla Firefox által is elfogadott CA-nak milyen folyamatokra és szabályzatokra van szüksége.

Tehát, ha CA-t importálunk, érdemes feltenni a kérdést: Az importált CA tulajdonosa vajon mennyire vigyáz a privát kulcsára? Aztán mindenki döntsön saját belátása szerint.

Kis demó frissen installált GNU/Linux 5.0 (lenny) esetén:

Készítsünk egy CA-t:

lenny:~/cert# openssl req -new -x509 -days 3650 -keyout private-cakey.pem -out cacert.pem
Generating a 1024 bit RSA private key
....++++++
......................................................++++++
writing new private key to 'private-cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:HU
State or Province Name (full name) [Some-State]:Budapest
Locality Name (eg, city) []:Budapest
Organization Name (eg, company) [Internet Widgits Pty Ltd]:AAA Tamado CA
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

Exportáljuk ki Firefox által is értelmezhető formátumban:

lenny:~/cert# openssl x509 -inform PEM -outform DER -in cacert.pem -out cacert.cer

Kirakjuk webre, ami jelen esetben csak a saját gép:

lenny:~/cert# cp cacert.cer /var/www

A /etc/apache2/mods-available/mime.conf megfelelő részéhez írjuk be a következőt:

AddType application/x-x509-ca-cert .cer

Majd Apache újraindítás:

lenny:~/cert# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting .

A mime típus beállítás nélkül nálam chemical/x-cerius típusúnak mondta a fájlt az Apache, így a Firefox nem ajánlotta fel a tanúsítvány telepítését, csak letölteni akarta azt. (Egyébként akár kézzel is importálhatjuk a CA-t: Szerkesztés / Beállítások / Haladó / Titkosítás / Tanúsítványkezelő / Hitelesítésszolgáltatók / Importálás, majd keressük ki a cacert.cer fájlt.)

Ezután ha Firefoxban beírjuk a http://localhost/cacert.cer címet, feljön a következő ablak:

Firefox böngészővel egy CA publikus kulcsát tartalmazó cer fájlra kattintás után megjelenő ablak, amelyben a böngésző megkérdezi, hogy akarjuk-e importálni a tanúsítványt, illetve megbízni abban.

Pipa az első checkboxba és OK. Ezzel be is került a hitelesítésszolgáltatók listájába a CA-nk (Szerkesztés / Beállítások / Haladó / Titkosítás / Tanúsítványkezelő / Hitelesítésszolgáltatók vagy Edit / Preferences / Advances / Encryption / View certificated / Authorities angol Firefox esetén).

Ha ezt megcsinálta a kliens, akkor készítsünk egy tanúsítványt a tamadottnetbank hoszthoz.

Először egy privát kulcsra lesz szükségünk:

lenny:~/cert# openssl genrsa -des3 -out tamadottnetbank.key 1024
Generating RSA private key, 1024 bit long modulus
.++++++
..................................++++++
e is 65537 (0x10001)
Enter pass phrase for tamadottnetbank.key:
Verifying - Enter pass phrase for tamadottnetbank.key:

Szedjük le a jelszót a privát kulcsról, az Apache-hoz úgysem kell:

lenny:~/cert# cp tamadottnetbank.key tamadottnetbank.key.org
lenny:~/cert# openssl rsa -in tamadottnetbank.key.org -out tamadottnetbank.key
Enter pass phrase for tamadottnetbank.key.org:
writing RSA key

Ezután készítsünk egy CSR-t (Certificate Signing Request), amit a CA alá tud írni:

lenny:~/cert# openssl req -new -key tamadottnetbank.key -out tamadottnetbank.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:HU
State or Province Name (full name) [Some-State]:Budapest
Locality Name (eg, city) []:Budapest
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tamado    
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:tamadottnetbank
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Írjuk alá a CA-val a CSR-t:

lenny:~/cert# openssl x509 -req -in tamadottnetbank.csr -CA cacert.pem -CAkey \ 
private-cakey.pem -CAcreateserial -out tamadottnetbank.crt
Signature ok
subject=/C=HU/ST=Budapest/L=Budapest/O=Tamado/CN=tamadottnetbank
Getting CA Private Key
Enter pass phrase for private-cakey.pem:

Majd másoljuk be az Apache által várt helyre:

lenny:~/cert# cp tamadottnetbank.key /etc/ssl/private/ssl-cert-snakeoil.key
lenny:~/cert# cp tamadottnetbank.crt /etc/ssl/certs/ssl-cert-snakeoil.pem

(A SSLCertificateFile és SSLCertificateKeyFile Apache beállítások mondják meg a fájlok pontos helyét, amik Lenny alatt a fentiek.) Egy biztonsági mentés nem árthat, én most kihagytam.

Apache SSL engedélyezés és újraindítás:

lenny:~# a2ensite default-ssl
Enabling site default-ssl.
Run '/etc/init.d/apache2 reload' to activate new configuration!
lenny:~# a2enmod ssl
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.
Run '/etc/init.d/apache2 restart' to activate new configuration!
lenny:~# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting .

A /etc/hosts fájl végére a következő kell még:

127.0.0.1 tamadottnetbank

Végül az eredmény, ha a https://tamadottnetbank/ oldalra navigálunk:

Firefox böngésző képernyőképe a tamadottnetbank oldalra navigáláskor. A képen látszik, hogy https kapcsolatról van szó, és érvényes a weboldal tanúsítványa.

A turpisság persze hamar kideríthető, ha a címsoron rákattintunk a tamadottnetbank feliratra:

Firefox böngésző képernyőképe az tamadottnetbank oldalra navigáláskor. A képen látszanak a tanúsítvány részletei is, köztük az, hogy az oldal tanúsítványát a korábban létrehozott Tamado CA írta alá.

Ugyanez működik bármelyik létező weboldallal, a MITM miatt nincs különösebb jelentősége, hogy létezik-e a támadott oldal, vagy sem.

Egyébként hasonló elven működik a Microsoft Forefront Threat Management Gateway is. A TMG is egy CA, aminek a tanúsítványát telepíteni kell a kliensekre. A TMG hivatalosan is MITM-et művel, mivel rajta keresztül érik el az internetet a felhasználók. Az SSL kapcsolatokat saját maga végződteti, megvizsgálja a tartalmukat, majd ismét SSL-be csomagolva, immár saját maga által létrehozott és aláírt tanúsítvánnyal továbbítja a kliensnek.

Egy apróság: Jelenleg (3.6.10) CA törlése után újra felvenni a CA-t nem engedi a Firefox („Ez a tanúsítvány már telepítve van hitelesítésszolgáltatóként.” hibaüzenet), csak ha leokézzuk a tanúsítványkezelő ablakát, majd újra megnyitjuk.

Olvasnivaló:

Linkrövidítők

Őszintén utálom az olyan blogokat, ahol a kifelé mutató linkjeiket is (!) rövidítik valamelyik linkrövidítő szolgáltatással. Ezek az ördög művei, még akkor is, ha így lesz színes-szagos statisztika arról, hogy melyik linkre hányan kattannak. Nem is beszélve a dolog privátszférás vonzatairól. Meg majd jól megszűnik a szolgáltató, aztán elvesznek sok év linkjei. A blogger meg írhatja át a régi linkjeit – jobb esetben a rendes linkekre, rosszabb esetben egy újabb linkrövidítőére. De nem is kell megszűnnie, elég ha csak időnként nem működik valamiért. I see dependencies, ha pólófeliratot akarnék.

Kicsit barátságosabb lenne, ha a rövidítés része kimaradna, például valami rov.id/id=0x1234&orig=http://eredetili.nk formátumot használnának. Erre lehetne szkriptet, plugint írni, de enélkül muszáj használni a linkrövidítő szerverét.

Twitteren is baromi gusztustalan, hogy nem tudja az ember mire kattint.

További nyalánkságok: URL shortening - Criticism and problems.

Adatbányász-barát, privacy ellenes RSS

Pár éve, Adatbányászati alkalmazások c. tantárgyamhoz írtam a következő szösszenetet.

Mondjuk ilyen egy alap RSS:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"
 "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<rss version="0.91">

<channel>
<title>bme feeds</title>
<link>http://akarmii.hu/</link>
<description>bme feeds</description>
<language>hu-hu</language>

	<item>
		<title>bme-kth - Felvételi - Rajz alkalmassági vizsga beosztás</title>
		<link>http://www.kth.bme.hu/index.php?news_show&amp;amp;news_id=45546</link>
	</item>
	<item>
		<title>bme-kth - OEP-hez bejelentettek adatai</title>
		<link>http://www.kth.bme.hu/index.php?news_show&amp;amp;news_id=45538</link>
	</item>
</channel>
</rss>

Vannak más formátumok is, de szerintem a következő máshol is működik: Az oldalon az RSS-csatorna linkjét kell csak mindig változóan összeállítani, amire a felhasználó feliratkozik. Mondjuk ez az alap:

  • http://akarmii.hu/rss.xml

Ebből csinálhatunk ilyeneket, ha megvannak hozzá az adatok:

  • http://akarmii.hu/rss.xml?username
  • http://akarmii.hu/rss.xml?sessionid
  • http://akarmii.hu/rss.xml?randomnumber

A username a felhasználó neve az oldalon, ha nincs, akkor a cookie-ban lévő sessionid, amúgy meg generálhatunk minden oldalra egy véletlenszerű azonosítót. Elsőre ez utóbbi tűnik a legegyszerűbbnek, és ha nagy a lehetséges számok köre, akkor meg tudjuk hosszú távon is különböztetni egymástól a felhasználókat.

Ezután csak annyi kell, hogy ha az rss.xml (ami mondjuk egy PHP szkript, és nem statikus tartalom) talál valamit a kérdőjel után, azt a <link> tag-ek végére is beilleszti. Például:

<item>
	<title>bme-kth - OEP-hez bejelentettek adatai</title>
	<link>http://www.kth.bme.hu/index.php?news_show&amp;news_id=45538&id=rss_username</link>
</item>

Itt figyelni kell a megfelelő kódolásra, csak egy kérdőjel legyen az URL-ben stb., de megoldható.

Ezután ha RSS-ben található linkről jön vissza a felhasználó, akkor tudni fogunk róla. Adatbányászatnál pedig ugyanazok a módszerek használhatóak, mint a hírleveles adatbányászat esetén. Továbbá itt ténylegesen lehet figyelni, hogy benne van-e még az RSS olvasóban a csatornánk, hiszen azt az olvasóprogram periodikusan lekéri a szervertől.

Érdemes meghagyni, hogy az azonosító kitörlésével is működjön az RSS. Így azok is olvashatják a csatornát, akik nem akarják, hogy mindig tudjuk az IP-címüket.

Az RSS-hez még annyit, hogy ez közelebb áll az e-mailhez mint a böngészéshez abból a szempontból, hogy hányan használnak közösen egy e-mail címet, valamint egy böngészőt. Böngészőnél előfordulhat a közös használat, de ahogy az e-mail esetében is, az RSS-olvasónál valószínűleg nem lehet annyira jelentős. (Már csak az olvasott/nem olvasott hírek megkülönböztetésének igénye miatt is.)

Akadozó stream-ek mentése

Egy apró shell szkript, amely mindenféle, időnként megszakadó stream felvételére használható.

#!/bin/bash

URL=$1
while true
do
    DATE=`date +%Y%m%d_%H_%M_%S_%N`
    mplayer -dumpstream "$URL" -dumpfile ${DATE}.dump
    sleep 2
done

A kimenete elég sok fájl lesz, de cserébe akár ssh-n, X nélkül is futtatható.

JavaScript alert() végtelen ciklusban

Kissé vicces, hogy egy olyan DoS támadásra nem nyújt védelmet a Firefox, amiért már nyolc-kilenc éve is kitiltás járt az akkori IRC csatornáinkról. A címből már valószínűleg kiderült, a végtelen alert() JavaScript hívások sorozatáról van szó. A Google Chrome egész okosan megoldotta:

Kis keresgélés után két ilyen kiegészítőt találtam a Firefox-hoz: AlertCheck, AlertStopper.

Ha viszont már megtörtént a baj, és a meglévő munkamenetünket, megnyitott füleket sem akarjuk elveszteni, akkor a következő talán segíthet:

  • Nyiss egy új Firefox ablakot, és telepítsd fel a NoScriptet, vagy esetleg a fenti két kiegészítő egyikét.
  • Tűzfallal tiltsd le a problémás oldal hostját, IP címét.

Ha ezek közül megvan valamelyik, akkor Windows alatt a feladatkezelővel, Linux alatt pedig egy megfelelően paraméterezett kill paranccsal lődd ki a Firefox processzét. Újraindítás után remélhetőleg betölthető marad a összeomlott munkamenet, de NoScript esetén már nem fognak lefutni a JavaScriptek, tűzfalas tiltás esetén pedig a problémás oldal nem fog betöltődni. Ez utóbbit nem próbáltam. A tűzróka esetleg előhúzhatja a gyorsítótárból az oldal tartalmát, de ilyenkor a megnyitott új ablakban törölhető a cache tartalma is.

Tartalom elrejtése a keresők elől

A nevemre rákeresve most szerencsére egy olyan találatot sem láttam, ami tartalmazza a Neptun kódom - és fordítva is.

Nem mindig volt ez így, miközben nem nagy dolog elrejteni a keresők elől egy oldalt. A Google úgyis mindent indexel, ami felkerül a webre csak egy tévhit. Csupán elég a domain főkönyvtárába elhelyezni egy robots.txt-t, mondjuk valami ilyesmi tartalommal, hogy ne tegye ezt meg:

User-agent: *
Disallow: /titok/

Fontos, hogy a módszer csak akkor működik, ha a robots.txt a domain főkönyvtárában szerepel.

Ha oda nem tudunk írni, akkor viszont használható a következő HTML fejléc az indexelés, és pár más dolog tiltására:

<meta name="robots" content="noindex, nofollow, noarchive, nosnippet">

A robots.txt-ből persze kibányászhatóak az elrejtett oldalak, így egy okosabb látogató megtalálhatja azokat. A legbiztosabb megoldás persze a jelszavas védelem, de bizonyos esetekben a fentiek is elegendőek lehetnek (illetve lehetnének).

További olvasnivaló:

no-www és https

Találtam egy ilyet: www. is deprecated.
Meggyőző, úgyhogy a lap ezentúl Class-B (a www. át van irányítva a www nélküli címre).
Aztán ha minden igaz, akkor előbb-utóbb lesz normális tanúsítvány a https-hez.

linux.hu hírlevél

Nagyon sok éve jár már, de ma lemondtam a linux.hu-s hírlevelet. Kezdett az idegeimre menni, hogy egy hónapja mindegyik küldemény Az LME új irodavezetőt keres című hírrel kezdődik. Szerencsére van helyette RSS.

Tartalom átvétel