Излагането на вашите първични ключове (особено ако са предвидими) е уязвимост, наречена несигурна директна препратка към обект.
Като имате URL (или друг параметър, предоставен от клиента) като този:
http://www.domain.com/myaccount?userid=12
Давате възможност на крайните си потребители да се забъркват с тези променливи и да предават всякакви данни, които им харесват. Насрещната мярка за смекчаване на тази уязвимост е вместо това да се създават непреки препратки към обекти. Това може да звучи като голяма промяна, но не е задължително да е така. Не е нужно да ходите и да пренабирате всичките си таблици или нещо подобно, можете да го направите, просто като бъдете умни с данните си чрез използването на непряка референтна карта.
Помислете за това:имате потребител, който прави покупка на вашия сайт. И когато дойде време за плащане, им се показва падащо меню с номерата на техните кредитни карти, които имате „на досие“. Ако погледнете кода за падащото меню, ще видите, че номерата на кредитните карти са свързани с ключовете 8055, 9044 и 10099.
Потребителят може да погледне това и да си помисли, че те приличат много на автоматично нарастващи първични ключове (потребителят вероятно би бил прав). Така той започва да опитва други ключове, за да види дали може да плати с чужда карта.
Сега технически трябва да имате код от страна на сървъра, който гарантира, че избраната карта е част от акаунта на потребителя и че те могат да я използват. Това е измислен пример. Засега ще приемем, че това не е така или че това е друг тип формуляр, който може би няма такъв вид контрол от страна на сървъра.
И така, как да попречим на крайния потребител да избере ключ, който не трябва да е достъпен за тях?
Вместо да им показвате директна препратка към записа в БД, дайте им непряка препратка.
Вместо да поставяме DB ключовете в падащото меню, ще създадем масив на сървъра и ще го напълним в сесията на потребителя.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
В падащото меню сега предоставяме препратка към индекса на масива, където се съхранява картата. Така че вместо да види действителните ключове, крайният потребител ще види стойностите 0, 1 и 2, ако види източника.
Когато формулярът бъде изпратен, една от тези стойности ще бъде предадена. След това изваждаме масива от сесията на потребителя и използваме индекса, за да получим стойността. Действителният ключ никога не е напускал сървъра.
И потребителят може да предава различни стойности през целия ден, ако иска, но той никога, никога няма да получи резултат, различен от собствените си карти, независимо от контрола за достъп от страна на сървъра, който е на място.
Имайте предвид обаче, че когато използвате предадения индекс, за да получите стойността, ако потребителят се забърка с него, можете да получите някои изключения (ArrayOutOfBounds, InvalidIndex, каквото и да е). Така че увийте тези неща в try/catch, за да можете да потиснете тези грешки и да регистрирате неуспехите, за да търсите опити за кракване.
Надявам се това да помогне.
За да прочетете повече за несигурни директни препратки към обекти, вижте топ 10 на OWASP. Това е риск номер A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
