Няколко въпроса за изпита

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

IvoArsov 44 Точки

Няколко въпроса за изпита

Привет,

имам няколко въпроса, чиито отговор ще бъде полезен на доста хора:

1.За еднотипни бъгове в различни секция, отделни issues ли се пускат? Например: в чалгарския форум голяма част от бутоните и надписите не са ясно видими. Това с едно issue ли се минава?

2.Можем ли да "рисуваме" по screenshot-ите, стрелки и т.н.?

3.Ако намерим missconception в SRS-a, къде да го опишем?

4.При автоматизираните тестове, да тестваме ли за XSS атаки и SQL injections?

5.Като стана въпрос за SQL injections, какво е поведението на приложението ако има такава атака? Смисъл, в логин формата пишем

' OR 1=1;--

и какво се случва, ако не се ескеипне?

Благордаря предварително ;)

Тагове:

03/05/2016 14:30:42 QA Fundamentals

RoYaL Trainer 6849 Точки

Best Answer

Здравей,

1. По принцип би било хубаво да са отделни issue-та. Защото може поетапно да ги оправи програмиста. Поне така би било в реална среда. Ако видиш, че те притиска времето ги пусни в едно issue. Също разцъкай малко в JIRA "More" таба на issue-тата. Там има опция Clone, така че можеш едно issue да го клонираш.

2. Можеш да "цапаш" скрийншотите, ако сметнеш, че така по-добре ще разбере човека, на когото репортваш. Понякога даже е силно препоръчително.

3. Неяснотиите по спецификацията се репортват също в тракера. Изпращай ги до отговорния за спецификацията. В случая на изпита това е Project Manager-a.

4. Колкото по-широк е обхватът на автоматизирания тест, толкова по-добре. И в реална среда и на изпита, също. Ако имаш автоматизация, която тества за различни видове атаки, няма да ти се налага всеки ден да го правиш ръчно. Както може да регресира дадена функционалност, така може да регресира и сигурността на приложението. Аз лично препоръчвам преди да стигнеш до автоматизация на сигурността, да минеш през по-основните функционални тестове, като например дали дадената функционалност въобще работи по спецификация. В случая с коментарите на албумите това беше - дали гост може да коментира (съответния error box); дали регистриран може да коментира; дали админ може да коментира. Дали правилно се появява коментара. Дали е от правилния потребител. Дали е с правилната дата. След като минеш през тези, тогава ако остане време автоматизирай тестването на сигурността.

5. Няма one best scenario в тази случка. При логин форма, ако този скрипт мине, най-вероятно ще се логнеш с някой потребител. Евентуално първият в таблицата с потребители, който вероятно е администраторът. Ако си подкарал изпитите при теб, шансовете са, че имаш MySQL. На http://localhost:8023/phpmyadmin (или без 8023, ако не си оправял порта) имаш административен инструмент за достъп до MySQL. Пробвай през него да навигираш до таблицата с потребители на някой от изпитите. Има опция да филтрираш данните. През туулчето избери да филтрираш до някой потребител с парола и то ще ти генерира заявка. Нещо от рода на "SELECT * FROM users WHERE username = 'pesho' AND password = '!$f4553443ef645g457567';". Вземи тази заявка и я пусни в SQL табчето, само че вместо pesho сложи скрипта, и ще видиш какъв де факто е резултатът. SQL injection атаката прави точно това, каквото пише в името й. Инжектира SQL код в заявка, правейки я различна от очакваната за програмиста и евентуално удобна за съответния атакуващ. Най-честият начин да разбереш дали има такава дупка е кодът, който си дал, но може по някога и по-сложни заявки да трябва да се сложат, за да мине атаката (обикновено такива успяват да бъдат намерени, когато приложението е с отворен код).

Надявам се да съм успял да ти отговоря и да е било полезно и за останалите.

Поздрави,

Иван

03/05/2016 15:05:35

Petradj 4 Точки

Здрасти,

Относно "административен инструмент". Иска ми username and pass. Пробвах всичко възможно. admin/admin и т.н. Какво всъщност трябва да ползваме за логина?

07/05/2016 10:00:36 07/05/2016 10:01:03

IvoArsov 44 Точки

Username: root

password: {не пишеш нищо}

07/05/2016 12:16:53

anamariyat 9 Точки

Здравей,

Заинтригува ме 4-тият ти въпрос. Относно SQL injection, има около 10 различни типа атаки и е доста трудно да напишеш сам автоматизиран тест за това, който да ти даде реални резултати. Подобна е и ситуацията с XSS.

За тестване на XSS, CSRF, Path Traversal, SQL-i и тн. има специални тулове които обхващат повече видове атаки, а има и level of penetration, който може да избереш, спрямо това колко време за тестване имаш. Най-хубавото при ползване на такива тулове е, че след края на тестовете ти се генерира report описващ слабостите в системата приоритизирани, както и основни решения на появилите се проблеми.

Аз лично ползвам OWASP ZAP и смятам тула за много удобен и лесен за този тип тестване.

04/05/2016 19:18:09

IvoArsov 44 Точки

Добро утро,

благодаря, ще го имам впредвид.

05/05/2016 08:45:56

GerganaGeorgievaSuvandzhieva 19 Точки

Аз малко се обърквам с тези видове бъгове.

Според мен всеки един бъг, който открия, но не е описан във SRS-a , отива за одобрение от Project Manager-а, с изключение на някой важни security бъгове или дизайнерски, които са очеизвадни.

Но например ако цветът на бутон е в зелен цвят и той не е описан в SRS-a, не е правилно да репортвам до дизайнера, защото на мен не ми е харесало зеленото. Редно е ПМ-а да попита клиента и след това да предприеме действия за промяна или не.

Отделно имам и такова питане: Може ли бъг, който не е описан в СРС-а да бъде функционален или по-скоро в 90% е user acceptance ??? Ако е възможно да е функционален без да е описан в СРС-а бихте ли ми дали пример

А и всъщност в Jirata по-какъв начин ще покажем на проверяващите, че бъгът е функционален или cesurity , при положение , че и двата отиват към developer-a ??

Благодаря!

05/05/2016 21:12:00

IvoArsov 44 Точки

Здравей,

според мен, някои неща си имат поведение по подразбиране и не е нужно да се описва в спецификкацията. Например: във форум би било правилно, ако най-новите коментари са най-отгоре. Аз бих го описал като функционален бъг, ако в СРС-а не е споменато изрично някакво друго подреждане. Същото важи и за регистрационна форма, без потвърждение на паролата, например. Явно доста неща опират до преценка в частният случай.

Поздрави!

05/05/2016 21:57:39 05/05/2016 21:59:09