DevProTalk
Strana 1 od 2 1 2 >
Prikažite 40 poruka iz ove teme na jednoj stani

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Zaštita od hakovanja (http://www.devprotalk.com/showthread.php?t=1779)

Misko 07. 11. 2006. 16:38
Zaštita od hakovanja
 
Nisam neki vičan PHP koder (učim se polako) i imam jedan problem... imam skript (stranu) u kome se delovi učitavaju u zavisnosti od HTTP_GET_VARS-a, tj od parametara koje prosledim kroz link... u kodu to izgleda ovako

Kôd:
<?
$page=$HTTP_GET_VARS["p"];
?>
a onda gde mi je to potrebno štampam:

Kôd:
<? include $page.".php";?>
e sad u čemu je problem... dešava mi se da mi hakuju sajt :1092: :1027: i koriste ga za phishing. Ukapiram ja u čemu je problem ali neznam da ga rešim... pa je moje pitanje:

kako da proverim da li se fajl koji učitavam nalazi na mom serveru i ako se nalazi, onda da dopustim da se smesti u varijablu tj. odštampa gde je potrebno?

dinke 07. 11. 2006. 16:56
Sto bi rekao Harry Fuecks, ovaj tvoj nacin je "path to serious hair loss" :1064:

Elem, ako vec zelis da ukljucujes php strane u zavisnosti od request stinga, onda trebas da uradis sledece:

1) listu dozvoljenih vrednosti za tu 'page' variablu cuvas u nekom array-u tipa:

PHP kôd:
$allowed_pages = array('foo','foo1','foo2');
if(in_array($_GET['page'], $allowed_pages))
{
  //nastavljas sa inludom
}
else
{
  //neko pokusava da te hakuje!
} 
2) nemoj page variablu da zoves page, mozes da joj das neko manje smisleno ime koje potencijalnom hakeru nece odmah reci za sta se koristi.
3) Mozes koristiti jednostavan metod "kriptovanja" (ovo nije naravno pravo kriptovanje) sadrzaja query stringa sa base64_encode/base64_decode f-jama.

I naravno, nikada ne veruj onome sto ti stize sa druge strane (usera). Za vise informacija, mozda da potrazis "Php Architect Guide to Security", mislim da se tako zove knjiga.

Blood 07. 11. 2006. 17:36
Uh, kod koji sam postavio ne valja nista :)

Ako ti treba knjiga koju je Dinke spomenuo, javi mi se na pp i poslacu ti je...

Ilija Studen 07. 11. 2006. 17:51
Pretpostavimo da je struktura ovakva:

Kôd:
/pages/
/pages/homepage.php
/pages/about.php
index.php
index.php kroz koji idu svi zahtevi mogao bi da ide ovako:

PHP kôd:
$page = isset($_GET['page']) ? $_GET['page'] : 'homepage';
$page_path = dirname(__FILE__) . '/pages/' . $page . '.php';
if(is_file($page_path)) {
  include $page_path;
} else {
  die("A to bi ti!!! E nem're!");
} 

bluesman 07. 11. 2006. 18:00
Uh bre, Misko, pa to je jedna od prvih "NO-NO" stvari koje treba da naučiš. Ima dosta članaka na temu security i PHP, trebalo bi da potrošiš par dana da pročitaš to pa onda da prepraviš svoj kod.

Možda izgleda kao veliki napor, ali veruj mi da ćeš se rešiti glavobolja kao što je ova. Pročitaš jednom i "vozi miško" :)

misk0 07. 11. 2006. 18:08
Ilijin nacin ima i dobrih i losih stvari:
- na taj nacin, lako inkludujes nove stranice bez ikakvog 'instaliranja'
- isto tako haker moze tako da ukljuci stranice koje ti ne zelis da javno prikazes.

Jedan nacin bi bio da napravis (kako se zvase.... ) niz :
["p1"] = "page1.php";
["p2"] = "otherpage2.php";
........

Tako kad zelis da uradis include, prvo provjeris da li se element nalazi u nizu, ako jeste, inkludujes tacno stranicu koja je u nizu (a ti si napunio taj niz).

Ilija Studen 07. 11. 2006. 18:13
Način funkcionisanja ove skriptice je prilično jednostavan:

* sve što je u /pages može biti prikazano automatski, nema "instaliranja"...
* sve van /pages je nevidljivo skripti (tj. haker ne može da ga koristi)
* pošto se koriti apsolutni path nema protokola tako da nema učitavanja resursa spolja
* forsirana je .php ekstenzija tako da sama stranica mora da bude izvršiva

Ako nešto ne želi da bude dostupno kroz index.php neka ga ne stavalja u /pages. Jako jednostavno...

Ovo je jedno od onih "sipaš i ne misliš" rešenja. Strašno je jednostavno, a opet ga je teško oboriti.

Aleksandar.Ilic 07. 11. 2006. 18:58
Ajde jedno pitanje, ako neko zna odgovor. Da se nadovezem na ovu temu.

Imao sam bas ovakav nacin upada pre neki dan na mom serveru.
tip je bukalno imao kod ovog tipa:
Kôd:
if (isset($_GET['page])) {
  require($_GET['page]);
}

i sta se desilo....

dosao pametni haker i poslao kao parametar za page neki svoj url, i onda mu se u okviru ovog sajta otvorila neka web konzola. I on je bukvalno kroz konzolu mogao da uploaduje fajlve na moj server, i da pokrece programe na mom serveru. E sad. Kako moze da radi upload?? Aj to cu i da shvatim, ali kako bre moze na taj nacin da pokrene neki program koji se izvrsava na mom serveru :1027:
any hint?

Pedja 07. 11. 2006. 19:34
Onog momenta kada dodje u situaciju da izvrsi svoj PHP kod, moze da uradi sve sto je PHP-u doyvoleno a to manje/vise znaci sve.

imas u stvari jednostavan trik protiv toga, samo uvedi nekiprefiks za ime datoteke koju inkludujes tako daces da zeznes bilo kakav podmetnut sadrzaj. to je naravno samo brza precica, ali moze da odradi posao ko ti je nezgodno da odrzavas listu dozvoljenih skriptova.

Jos je bolja opciaj da oznaka strane budeneki id a da se na osnovi ID-a u stvari odnekud procitakoji se tacno skript ucitava. Tadane moras da radis neku veliku proveru, prosto ako ID nije definisan, prijavis gresku. Na taj nacin ustvari najbolje izolujes hakera od include i require.

misk0 07. 11. 2006. 19:44
Aleks: Nisam siguran, ali mislim da je moguce da ucita PHPShell i da na osnovu toga izvrsava fakticki bilo koju komandu. Ako nije to u pitanju, vidjao sam custom-made skripte koje dozvoljavaju takve akcije (cak sam imao tako nesto na disku).
Takodje nisam siguran (ideja) mislim da se u php.ini moze zabraniti include URL-a unutar parametara ili tako neka fora, ne znam na pamet.

dinke 07. 11. 2006. 19:53
Citat:
Originalno napisao Ilija Studen
Ovo je jedno od onih "sipaš i ne misliš" rešenja. Strašno je jednostavno, a opet ga je teško oboriti.
A sta ako user posalje nesto tipa page = ../../../foo ? ladno ce taj fajl traziti ispod page dira o kome pricas. Sve u svemu, vrlo insecure.

Br@nkoR 07. 11. 2006. 20:15
>= PHP 5.1.0

//php.ini
Kôd:
allow_url_include = Off
edit:

a postoji i allow_url_fopen

Aleksandar.Ilic 07. 11. 2006. 20:20
hm, ja licno znam za taj allow_url_include. I nije meni problem da zastitim svoj kod protiv ovakvih napada. Stavise, nijedna moja skripta nije ranjiva na ovakav tip napada. Nego mene zanima kako da napravim skriptu koja moze se tako includuje preko url-a i da radi na server na kome je includovana :)

Pedja 07. 11. 2006. 20:38
Pa napravis kao i svaku drugu skriptu, samo moras da joj promenis ekstenziju da tvoj server posalje php kod a da ga ne izvrsi. Ovaj drugi include-uje sors i izvrsi ga.

Aleksandar.Ilic 07. 11. 2006. 21:07
lele, a ja sam mislio to neki teski hack :D Sramota :) Thnx

zark0vac 07. 11. 2006. 22:39
Hehe..
Sto se tice zastite od rfi-a, sledece stvari su korisne da se podese kako
navedem sem ukoliko je neophodno za funkcionisanje skripte da se ne menja.

Za pocetak ako ti skripta moze bez, obavezno iskljuci potencijalno opasne funkcije:

Kôd:
disable_functions=system,exec,passthru,shell_exec
Ovime si onemogucio pokretanje php shell skripti (r57, c99..) i samim tim
ozbiljniju stetu na serveru, ali ako nisi u mogucnosti to da uradis, ali i ako
jesi, u svakom slucaju procitaj ceo post i preporucljivo je da poslusas. :)

Zatim nacin za zabranu pozivanja fajla van odredjenog direktorijuma se moze
odraditi sa array-om kao sto je navedeno na 1 strani, ali ako ne zelite tako,
mozda vam ovaj kod moze pomoci:

Kôd:
<?php
  $folder = 'moduli/';
  $ekst = '.php';
  $modul = str_replace(".","",$_GET["modul"])

  if ( file_exists($folder.$modul.$ekst) ) {
  $fajl = $folder.$modul.$ekst;
  include($fajl);
  } else {
  echo "404 Not found";
}

?>
Postoji mogucnost da se uploaduje preko ovog koda i fajlovi koji
nisu sa .php ekstenzijom ali se nalaze u direktorijumu moduli/.
Primer:

Kôd:
http://www.serv.com/include.php?modul=nesto.txt?
# cime postaje: modul/nesto.txt?.php i zanemarena je .php ekstenzija,
# primer broj 2:
http://www.serv.com/include.php?modul=nesto.txt%00
# isto samo sto se ovime sav nastavak posle nesto.txt zanemaruje zbog
# null chara.
Za prosledjivanje vrednosti koristi $_POST umesto _request-a,
a $_get koristi samo tamo gde je namenjen, forsiraj post metod.
Zatim iskljuci register_globals i allow_url_fopen, i gledaj kod skripti :)
Preporucujem ti da pregledas security deo php manuala, dosta
ces nauciti o ovim napadima. Takodje se pozabavi sql injectionom,
daleko manje opasnim xss-om i komplikovanijimm csrf-om (ako je
manji projekat, csrf mozes zaobici, za sad :) ).

Ako imas dedicated onda ili unajmi nekog security experta da ti
podesi sistem kako i kada bi doslo do includeovanja php shell skripte
i dizanje nc-a da napadac ne moze da roota server, ali i redovno
skidaj patcheve za sve daemone/servise koje se vrte na tvoj boxu...

Nadam se da sam pomogao...

oliver 07. 11. 2006. 23:30
Citat:
Originalno napisao dinke
A sta ako user posalje nesto tipa page = ../../../foo ? ladno ce taj fajl traziti ispod page dira o kome pricas. Sve u svemu, vrlo insecure.
quickfix :)

PHP kôd:
$page = isset($_GET['page']) && strpos("../",$_GET['page']) === false ? $_GET['page'] : 'homepage'; 

bluesman 07. 11. 2006. 23:33
ili instaliras mod_security :) Ono sto sve zive nervira, ali radi pos'o :)

ivanhoe 07. 11. 2006. 23:47
ma bre Ilija sta fali tome da imas niz u kome pisu sve stranice koje je moguce inkludovati...ccc, sto ste bre toliko lenji...ova omladina, sve bi automatski :D

em je znatno sigurnije, em kad otvoris kod posle x meseci znas odmah koje strane se ukljucuju za koji ulazni parametar, bez da trazis po direktorijumima i tumacis mogucnosti...

dinke 07. 11. 2006. 23:54
jel to pokusavas da mi kazes da i ja trebam da stavim "old school" u svoj potpis ;) ?

Aleksandar.Ilic 07. 11. 2006. 23:55
Pa to je i najsigurniji nacin. Ja uvek hardkodiram inkludovanja. Manje boli glava, kod nije sporiji i naravno, definitivno je daleko pregledniji.
Samo sto eto, neki zele da pisu sto manji kod :), jer ih mrzi da kucaju (ponekad) par desetina puta include (require)

Ilija Studen 08. 11. 2006. 00:17
Citat:
Originalno napisao dinke
A sta ako user posalje nesto tipa page = ../../../foo ? ladno ce taj fajl traziti ispod page dira o kome pricas. Sve u svemu, vrlo insecure.
100% si u pravu. Rupčaga!

PHP kôd:
if(!preg_match("/^([a-zA-Z0-9_]*)$/", $page)) {
  die('Invalid file name');
} // if 
Ili još jednostavnije:

PHP kôd:
if(strpos($page, '.') !== false) {
  die('Invalid page name');
} // if 
Citat:
Originalno napisao ivanhoe
ma bre Ilija sta fali tome da imas niz u kome pisu sve stranice koje je moguce inkludovati...ccc, sto ste bre toliko lenji...ova omladina, sve bi automatski :D

em je znatno sigurnije, em kad otvoris kod posle x meseci znas odmah koje strane se ukljucuju za koji ulazni parametar, bez da trazis po direktorijumima i tumacis mogucnosti...
Ručno moraš da edituješ fajl ako nešto dadaš što je ponekad smor. Oba će raditi posao bez ikakvih problema, tako da je sve manje više stvar ukusa... Ipak više volim kada skripta radi veći deo prljavog posla za mene.

Btw, ja bih od ovoga napravio klasu :) Prima dva parametra - odakle da pokupi ime stranice i gde su smeštene stranice. Dokle god je interfejs klase čitak bole me uvo šta je ispod haube. Tipa:

PHP kôd:
$dispatcher = new Dispatcher(dirname(__FILE__) . '/pages');
$dispatcher->dispatch(@$_GET['page']); 
:p

ivanhoe 08. 11. 2006. 03:06
pa, uvek moze da se napravi zaseban ini fajl sa spiskom fajlova za include.. tako izbegavas editovanje koda...

Ivan 08. 11. 2006. 03:41
Hm, vidim da je ovde iznete dosta pametnih stvari ali ajde da probam da sumiram ...

Prvo i najvaznije pravilo koje svi treba da zapamtimo je: Filtrirati ulaz i escajpapovati izlaz.

Sto znaci da ulazni podaci mogu biti samo oni koje nasa aplikacija moze i sme da koristi. U konkretnom slucaju, najpamentnije resenje sa gledista sigurnosti je koriscenje switch-a. Tj za svaki zahtev postoji deo koda koji barate njime. Sve ostale metode se mogu lakse ili teze exploitovati, dodavanjem specijalnih karaktera ili losom konfiguracijom servera. Dalje npr, ako su nam potrebni samo brojevi u nasam scriptu koje dobijamo preko GET-a onda ogranicite te varijable na brojeve. Ne ostavljajte mesta za nehendlovane situacije.
Sto se tice izlaza, uvek treba prikazivati samo ono sto smemo da prikazemo a to znaci da sav kod koji moze da se izvrsi u browseru usera a ne treba biti izvrsen treba sanitizovati.

Za pocetak je dovoljno poslusati ovaj savet gore jer cete se tim nacinom kodovanja osloboditi vecine XSS, CSLF, SQL injectiona, Directory Traversal, include propusta ...
Neko je vec rekao da treba forsirati POST sto je delimicno tacno jer ce tako skinuti scriptkiddie sa vrata ali to ipak nije pravo resenje.

Citat:
$page = isset($_GET['page']) ? $_GET['page'] : 'homepage';
Ovakav nacin pisanja koda (Ternary Operator) nije pozeljan zbog preglednosti koda.

Neko je pomenuo mod_security, a takodje i neka podesvanja u samom php-u ... Sve ovo resava neke sigurnosne probleme ali poenta je napisati siguran kod bez pomocnih sredstava jer u svakom trenutku moze doci do promene konfiguracije servera.

Citat:
Za vise informacija, mozda da potrazis "Php Architect Guide to Security", mislim da se tako zove knjiga.
Za pocetak:
http://phpsecurity.org/
http://phpsec.org/projects/guide/sr/

E kad ovo predjete onda krece pravo zezanje :p Ajax, CSRF, i sl ...

dee 08. 11. 2006. 11:46
Citat:
Originalno napisao Blood
Uh, kod koji sam postavio ne valja nista :)

Ako ti treba knjiga koju je Dinke spomenuo, javi mi se na pp i poslacu ti je...
trebalo bi meni...imas li jos koji primjerak? :)

Ilija Studen 08. 11. 2006. 12:03
Citat:
Originalno napisao ivanhoe
pa, uvek moze da se napravi zaseban ini fajl sa spiskom fajlova za include.. tako izbegavas editovanje koda...
Ali dodaješ editovanje ini fajla. Šta si time dobio? Ništa... Još jedan fajl viška i dodatnu kompleksnost jer moraš da ga učitaš, parsiraš, izvučeš vrednost. Rad sa nizom unutar index.php je bolje rešenje od toga.

Pazi ovo, samo malo discipline i zdravog razuma: u /pages direktorijum samo stavljaš one stranice koje želiš da budu dostupne kroz index.php, nikakve druge gluposti. To je prvo i poslednje pravilo. Skripta radi ostatak.

Off Topic:
Citat:
Originalno napisao Ivan
Ovakav nacin pisanja koda (Ternary Operator) nije pozeljan zbog preglednosti koda.
Sorry, već sam par puta od jutros krenuo da odgovorim pa zatvorio reply prozor. Ipak ne mogu da se suzdržim. Moram:

:1075:

TO je izuzetno praktična stvar dokle god ga koristiš sa osnovnom dozom zdravog razuma, a trudim se da verujem da je prosečan PHP developer ima ;)


Bah, i evo mene opet u ovakvim diskusijama i sa istim tonom. A obećao sam da neću više :D

ivanhoe 08. 11. 2006. 16:42
Citat:
Originalno napisao Ilija Studen
Ali dodaješ editovanje ini fajla. Šta si time dobio? Ništa... Još jedan fajl viška i dodatnu kompleksnost jer moraš da ga učitaš, parsiraš, izvučeš vrednost. Rad sa nizom unutar index.php je bolje rešenje od toga.
ilija, nisi slusao na casovimal :)
PHP kôd:
$ini_array = parse_ini_file("sample.ini"); 
ini fajl je laksi za odrzavanje nego niz, a i malkice je brze nego include php fajla (jedino ne znam da li je podrzano kesiranje rezultata od strane akceleratora ? )

Misko 08. 11. 2006. 18:47
Uhhh... ovo se zove serija konstruktivnih odgovora... hvala puno svima... rešio sam problem :1042:

Ilija Studen 08. 11. 2006. 18:54
Citat:
Originalno napisao ivanhoe
ilija, nisi slusao na casovimal :)
Ništa novo ni iznenađujuće ;) Ja sam na časovima programiranja čitao "Očevi i oci" i još par naslova (za Očevi i oci znam sigurno jer mi je profesorica oduzela knjigu i rekla da će se žaliti razrednoj; nije mi išlo u glavu što bi se bilo ko žalio na tako dobru knjigu? :D ).

Citat:
Originalno napisao ivanhoe
ini fajl je laksi za odrzavanje nego niz, a i malkice je brze nego include php fajla (jedino ne znam da li je podrzano kesiranje rezultata od strane akceleratora ? )
Ček, ček. Hoćeš da kažeš da je:

PHP kôd:
$ini_array = parse_ini_file("sample.ini"); 
Brže od:

PHP kôd:
$allowed_pages = array('home', 'about', 'contact'); 
Ovo drugo sam imao na umu kada sam rekao "rešenje sa nizom" (Dinke je prvo to ponudio). Niz je unutar index.php jer nema poente da bude spolja.

Zip...

oliver 08. 11. 2006. 19:12
Citat:
Originalno napisao dee
trebalo bi meni...imas li jos koji primjerak? :)
ajd i meni, cini mi se da nemam to u "arhivi".

...ili okacite na Host011 tracker :)

zark0vac 08. 11. 2006. 19:27
Ja sam svakako za koriscenje nizova i samo nizova sem kada je izricito receno da se ne radi sa nizovima :-))

Najlaksa 100% sigurna varijanta.

Ivan 08. 11. 2006. 19:30
Citat:
@Ilija:
TO je izuzetno praktična stvar dokle god ga koristiš sa osnovnom dozom zdravog razuma, a trudim se da verujem da je prosečan PHP developer ima
Da, prosecan pa i napredniji PHP developer je veoma razuman covek koji ipak pravi greske. Ova preporuka koju sam naveo je preporuka vodecih security experata koju sam ja samo preneo (i da slazem se sa njom).
Ako te zanima zasto je to tako, onda malo vise procitaj ili razmisli o tome ...

Btw, spusti se na zemlju jer ni tvoj kod nije bas tako siguran ... :1074:

ivanhoe 08. 11. 2006. 19:36
Citat:
Originalno napisao Ilija Studen
Ček, ček. Hoćeš da kažeš da je:

PHP kôd:
$ini_array = parse_ini_file("sample.ini"); 
Brže od:

PHP kôd:
$allowed_pages = array('home', 'about', 'contact'); 
ne naravno :), samo sam nudio varijantu da mozes da napravis svoju klasu, i da omogucis da se ne menja php kod pri svakom dodavanju fajla (menjas samo ini koji je jednostavne strukture, znaci minimalne sanse za gresku)...i sve je divno i uredno, a jos i sigurno... and they lived happily ever after :1042:

Blood 08. 11. 2006. 19:37
Citat:
Originalno napisao oliver
ajd i meni, cini mi se da nemam to u "arhivi".

...ili okacite na Host011 tracker :)
heh, za ovo nisam ni znao - kacim o'ma sada... :P


POzdrav!

EDIT By Dinke:
Bez warez linkova na forumu! Kome treba moze da koristi pp za razmenu.

zira 08. 11. 2006. 20:00
Citat:
Originalno napisao Ivan
Btw, spusti se na zemlju jer ni tvoj kod nije bas tako siguran ... :1074:
Cemu ovakvo "spustanje", Ivane? :1050:

Ivan 08. 11. 2006. 20:24
OMG, ne ponovo ...

Odgovorio sam tako zbog Ilijinog stava.
Zar nije bilo bolje da pita zasto je tako to sto sam napisao ? Ne, on je odmah rekao da pricam gluposti ...

Ilija Studen 08. 11. 2006. 20:25
Citat:
Originalno napisao Ivan
Ako te zanima zasto je to tako, onda malo vise procitaj ili razmisli o tome ...
Baš me zanima to o potencijalnim opasnostima. Može neki link ili objašnjenje?

Citat:
Originalno napisao Ivan
Btw, spusti se na zemlju jer ni tvoj kod nije bas tako siguran ... :1074:
Kakve to veze ima sa čitljivošću TO-a? Osim u detinjastom kontekstu a-la "Moj tata jači od tvog tate!" ili "Ceca je bolja riba od Brene!"? Molio bih da me poštediš toga... Hvala.

Što se sigurnosnih propusta u activeCollabu tiče ljudi su ih prijavljivali, ja sam ih ispravljao i tako dan za danom, pred kockastim ekranom. Sudbina većine web aplikacija koje počnu da se distribuiraju je da pre ili kasnije nalete na sigurnosne probleme. Ja new kid on the block, a takvo tržište (sistemi su heterogeni, ne možeš da pružiš auto update itd)... Pogreši čovek. Ono što je bitno je vreme u kome možeš da reaguješ i doturiš pokrpljen kod korisnicima.

Btw, govorio si o ČITLJIVOSTI koda ;)

Ivan 08. 11. 2006. 20:32
@Ilija
Zbog tvog oholog stava ostavicu te da mislis o temi ...

Ilija Studen 08. 11. 2006. 20:38
Sorry, ali sve što vidim je verbalni terorizam (a must read tekst btw).

Btw, za ovu priču automatsko razrešavanje lokacije fajla koji sadržaj stranice vs. definisanje niza ili ini fajla naiskrenije sam ubđen da je prvo bolje rešenje. Dodaje na kompleksnosti aplikacije, ali smanjuje kompleksnost korišćenja jer ukida jedan korak pri definisanju novog sadržaja (to je inače jedan od principa razvoja koji smatram da je OK). Sorry ako je zvučalo oholo (pošto mi to uopšte nije bila namera). Sve je bilo samo posmatranje par konkurentnih rešenja - njihove prednosti i mane.

zark0vac 08. 11. 2006. 21:42
Svaka cast za link Ilija.
Najbolje mi je: Primetio sam da su oni koji se ne slažu sa mojom sledećom tezom uglavnom neobrazovani. [sledi teza] aka Najbolje je koristiti nizove/ini fajl/ automatsko razresivanje stranica, ko se ne slaze neka procita malo vise literature... :-))


Vreme je GMT +2. Trenutno vreme je 16:40.
Strana 1 od 2 1 2 >
Prikažite 40 poruka iz ove teme na jednoj stani

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.