<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/MustLive Edition" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Коментарі для запису: Уразливості на kpi.ua</title>
	<link>http://websecurity.com.ua/4220/</link>
	<description></description>
	<pubDate>Mon, 20 Apr 2026 09:17:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=MustLive Edition</generator>

	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/4220/#comment-344350</link>
		<pubDate>Sat, 11 Dec 2010 13:00:56 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-344350</guid>
					<description>Більшість хостерів зі своєї сторони не дуже слідкують за безпекою і, враховуючи суцільну дірявість сайтів їх клієнтів, то це створює ризики масових взломів - коли через один сайт взломають одразу всі сайти на сервері. Тому і хостери, і власники сайтів повинні слідкувати за безпекою (і якщо власник сайта має свій виділений сервер, то він повинен слідкувати і за тим, і за тим).

&lt;blockquote&gt;А такі серйозні вразливості в хостах я зустрічав доволі частенько.&lt;/blockquote&gt;
Дірки на сайтах, що дозволяють читати довільні файли, чи навіть мати повний доступ до файлової системи, мені трапляються часто. Проте в більшості випадків мені трапляються сайти, де нормально налаштовані права на сервері, що до сайтів інших аккаунтів не дістатися. Але враховуючи, що в 99% на сервері можуть бути дірки, які дозволять підняти права до рута, то вірогідність атаки на інші сайти дуже висока.</description>
		<content:encoded><![CDATA[<p>Більшість хостерів зі своєї сторони не дуже слідкують за безпекою і, враховуючи суцільну дірявість сайтів їх клієнтів, то це створює ризики масових взломів - коли через один сайт взломають одразу всі сайти на сервері. Тому і хостери, і власники сайтів повинні слідкувати за безпекою (і якщо власник сайта має свій виділений сервер, то він повинен слідкувати і за тим, і за тим).</p>
<blockquote><p>А такі серйозні вразливості в хостах я зустрічав доволі частенько.</p></blockquote>
<p>Дірки на сайтах, що дозволяють читати довільні файли, чи навіть мати повний доступ до файлової системи, мені трапляються часто. Проте в більшості випадків мені трапляються сайти, де нормально налаштовані права на сервері, що до сайтів інших аккаунтів не дістатися. Але враховуючи, що в 99% на сервері можуть бути дірки, які дозволять підняти права до рута, то вірогідність атаки на інші сайти дуже висока.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/4220/#comment-344348</link>
		<pubDate>Sat, 11 Dec 2010 12:10:24 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-344348</guid>
					<description>Серед згаданих мною &lt;a href="/4749/" rel="nofollow"&gt;уразливостей в Drupal&lt;/a&gt;, частина дірок має місце і на kpi.ua.</description>
		<content:encoded><![CDATA[<p>Серед згаданих мною <a href="/4749/" rel="nofollow">уразливостей в Drupal</a>, частина дірок має місце і на kpi.ua.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: Dementor</title>
		<link>http://websecurity.com.ua/4220/#comment-327184</link>
		<pubDate>Sun, 13 Jun 2010 11:56:48 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-327184</guid>
					<description>Я з тобою повністю згоден. Правда в людей не завжди є гроші на хорошого хостера, або вони прсто в цьому мало що розуміють, і беруть що є. А такі серйозні вразливості в хостах я зустрічав доволі частенько.</description>
		<content:encoded><![CDATA[<p>Я з тобою повністю згоден. Правда в людей не завжди є гроші на хорошого хостера, або вони прсто в цьому мало що розуміють, і беруть що є. А такі серйозні вразливості в хостах я зустрічав доволі частенько.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/4220/#comment-327074</link>
		<pubDate>Sat, 12 Jun 2010 20:44:17 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-327074</guid>
					<description>Як я вже сказав в попередньому коментарі - якщо права будуть налаштовані й всі патчі на сервері поставлені, тоді взлом одного сайта не вплине на інші сайти. Тому при нормальному хостері від взлома сайта проблем для інших сайтів інших клієнтів не буде. Це інша справа, що не всі хостери такі :-).

&lt;blockquote&gt;Але все-таки злом хоста це вже прогалина в безпеці&lt;/blockquote&gt;
Щоб через один сайт дістатися до інших для цього потрібно мати доступ до файлової системи, що вже само по собі серйозна уразливість (для даного сайту, не кажучи вже про можливість доступу до інших сайтів на даному сервері).

І як я вже казав, при нормально налаштованому сервері (у нормального хостера) проблем для інших сайтів не буде - бо до них не зможуть добратися з похаканого сайта. Тільки до інших сайтів даного клієнта на даному сервері (але це вже будуть проблеми даного клієнта, що він через один дірявий сайт підставляє одразу всі свої сайти на даному сервері). Розміщення своїх сайтів на різних фізичних серверах допоможе уникнути даної ситуауції ;-).</description>
		<content:encoded><![CDATA[<p>Як я вже сказав в попередньому коментарі - якщо права будуть налаштовані й всі патчі на сервері поставлені, тоді взлом одного сайта не вплине на інші сайти. Тому при нормальному хостері від взлома сайта проблем для інших сайтів інших клієнтів не буде. Це інша справа, що не всі хостери такі <img src='http://websecurity.com.ua/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> .</p>
<blockquote><p>Але все-таки злом хоста це вже прогалина в безпеці</p></blockquote>
<p>Щоб через один сайт дістатися до інших для цього потрібно мати доступ до файлової системи, що вже само по собі серйозна уразливість (для даного сайту, не кажучи вже про можливість доступу до інших сайтів на даному сервері).</p>
<p>І як я вже казав, при нормально налаштованому сервері (у нормального хостера) проблем для інших сайтів не буде - бо до них не зможуть добратися з похаканого сайта. Тільки до інших сайтів даного клієнта на даному сервері (але це вже будуть проблеми даного клієнта, що він через один дірявий сайт підставляє одразу всі свої сайти на даному сервері). Розміщення своїх сайтів на різних фізичних серверах допоможе уникнути даної ситуауції <img src='http://websecurity.com.ua/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> .
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: Dementor</title>
		<link>http://websecurity.com.ua/4220/#comment-322563</link>
		<pubDate>Wed, 26 May 2010 06:08:59 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-322563</guid>
					<description>Я згоден, що проблеми людського фактору це не веб-безпека. Але все-таки злом хоста це вже прогалина в безпеці і велика, так як може постраждати не один сайт.</description>
		<content:encoded><![CDATA[<p>Я згоден, що проблеми людського фактору це не веб-безпека. Але все-таки злом хоста це вже прогалина в безпеці і велика, так як може постраждати не один сайт.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/4220/#comment-322545</link>
		<pubDate>Tue, 25 May 2010 20:54:33 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-322545</guid>
					<description>&lt;blockquote&gt;Ну погодься, що незавжди відсутність дірок захищає від злому.&lt;/blockquote&gt;
&lt;strong&gt;Dementor&lt;/strong&gt;

Це обов'язкова вимога. Бо якщо є дірки на сайті, то вірогідність взлому збільшується (і тим більше, чим більше дірок, особливо високого ризику).

Є ще питання соціальної інженерії та інші аспекти, що опосередковано відносяться до сайтів. Наприклад, можна змусити жертву самій розповісти свій логін і пароль від сайта - але це не відноситься до питань веб безпеки, це вже питання соціальної інженерії. Можна фізічно вломитися в серверну і забрати сервер (наприклад, як це &lt;a href="/3799/" rel="nofollow"&gt;трапилося торік&lt;/a&gt;) - але це вже не питання веб безпеки, а фізичної безпеки. Можна загнати адміну на компьютер вірус і дістати логіни й паролі до адмінки чи ftp - але це вже не питання веб безпеки, а локальної безпеки (на локальному компьютері).

Ми ж говоримо про веб безпеку. А до неї відносяться уразливості на сайтах та веб додатках. З чого випливає, що дірок бути не повинно ;-). Атаки через хостінг на інші сайти трапляються - але це вже питання хостера (нажаль на вибір надійного хостера мало хто звертає увагу). Щоб права були налаштовані й всі патчі на сервері поставлені, тоді взлом одного сайта не вплине на інші сайти.</description>
		<content:encoded><![CDATA[<blockquote><p>Ну погодься, що незавжди відсутність дірок захищає від злому.</p></blockquote>
<p><strong>Dementor</strong></p>
<p>Це обов&#8217;язкова вимога. Бо якщо є дірки на сайті, то вірогідність взлому збільшується (і тим більше, чим більше дірок, особливо високого ризику).</p>
<p>Є ще питання соціальної інженерії та інші аспекти, що опосередковано відносяться до сайтів. Наприклад, можна змусити жертву самій розповісти свій логін і пароль від сайта - але це не відноситься до питань веб безпеки, це вже питання соціальної інженерії. Можна фізічно вломитися в серверну і забрати сервер (наприклад, як це <a href="/3799/" rel="nofollow">трапилося торік</a>) - але це вже не питання веб безпеки, а фізичної безпеки. Можна загнати адміну на компьютер вірус і дістати логіни й паролі до адмінки чи ftp - але це вже не питання веб безпеки, а локальної безпеки (на локальному компьютері).</p>
<p>Ми ж говоримо про веб безпеку. А до неї відносяться уразливості на сайтах та веб додатках. З чого випливає, що дірок бути не повинно <img src='http://websecurity.com.ua/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> . Атаки через хостінг на інші сайти трапляються - але це вже питання хостера (нажаль на вибір надійного хостера мало хто звертає увагу). Щоб права були налаштовані й всі патчі на сервері поставлені, тоді взлом одного сайта не вплине на інші сайти.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: Dementor</title>
		<link>http://websecurity.com.ua/4220/#comment-322456</link>
		<pubDate>Sun, 23 May 2010 07:16:20 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-322456</guid>
					<description>Ну погодься, що незавжди відсутність дірок захищає від злому. Так як може бути зломаний хостинг чи сусідній сайт, хоча це уже не зовсім злом конкретного сайту, але все ж, добратися до нього можна.</description>
		<content:encoded><![CDATA[<p>Ну погодься, що незавжди відсутність дірок захищає від злому. Так як може бути зломаний хостинг чи сусідній сайт, хоча це уже не зовсім злом конкретного сайту, але все ж, добратися до нього можна.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/4220/#comment-322393</link>
		<pubDate>Sat, 22 May 2010 15:32:41 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-322393</guid>
					<description>Так витоків інформації, як FPD, так й інших вистачає на сайтах. Зокрема такий витік інформації, як версія додатку. І як версії в хедерах сервера, так і версії веб додатків потрібно випрвляти.

Про різні Information Leakage уразливостей я писав чимало. Зокрема я зробив 4 статті про &lt;a href="/4074/" rel="nofollow"&gt;витік інформації про версію системи&lt;/a&gt; (і з часом зроблю нові статті). В тому числі в другій статті з даної серії я описав і дану уразливість в Drupal.

Одне діло якщо у людей на сайті власний движок, який ніде більше не використовується, то можна і розмістити на сайті версію движка. Інша справа коли у людей на сайті популярний движок (що опенсорсний, що закритий) - тут вже небезпечно повідомляти про його версію. Але в будь-якому разі не треба мати дірок на сайті ;-), тоді його не взломають (незалежно від виведення версії движка).</description>
		<content:encoded><![CDATA[<p>Так витоків інформації, як FPD, так й інших вистачає на сайтах. Зокрема такий витік інформації, як версія додатку. І як версії в хедерах сервера, так і версії веб додатків потрібно випрвляти.</p>
<p>Про різні Information Leakage уразливостей я писав чимало. Зокрема я зробив 4 статті про <a href="/4074/" rel="nofollow">витік інформації про версію системи</a> (і з часом зроблю нові статті). В тому числі в другій статті з даної серії я описав і дану уразливість в Drupal.</p>
<p>Одне діло якщо у людей на сайті власний движок, який ніде більше не використовується, то можна і розмістити на сайті версію движка. Інша справа коли у людей на сайті популярний движок (що опенсорсний, що закритий) - тут вже небезпечно повідомляти про його версію. Але в будь-якому разі не треба мати дірок на сайті <img src='http://websecurity.com.ua/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> , тоді його не взломають (незалежно від виведення версії движка).
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: Dementor</title>
		<link>http://websecurity.com.ua/4220/#comment-322362</link>
		<pubDate>Sat, 22 May 2010 10:26:57 +0000</pubDate>
		<guid>http://websecurity.com.ua/4220/#comment-322362</guid>
					<description>Доречі як я помітив досить таки часто зустрічається подібне. Мало хто (на жаль) розуміє як можна використати Information Leakage в тій чи іншій ситуації, на перший погляд той же changelog чи ще якісь коменти розробників здаються безпечними.</description>
		<content:encoded><![CDATA[<p>Доречі як я помітив досить таки часто зустрічається подібне. Мало хто (на жаль) розуміє як можна використати Information Leakage в тій чи іншій ситуації, на перший погляд той же changelog чи ще якісь коменти розробників здаються безпечними.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
