Har någon någonsin funderat på att göra det här?

Ja, det pratades faktiskt om exakt detta på defcon 21 ( video, bilder).

Deras slutsats var att arbeta med svarkoder som stötande säkerhet ibland kan leda till att bromsa automatiska skannrar, icke-fungerande skannrar och en enorm mängd falska positiva effekter eller falskt negativa (det kommer uppenbarligen att göra lite eller ingenting för manuella skanningar).

Även om säkerhet genom dunkelhet aldrig bör vara ditt enda försvar kan det vara fördelaktigt som djupförsvar (ett annat exempel: det rekommenderas att sänder inte versionsnummer för alla använda komponenter).

Å andra sidan borde ett REST API vara så rent som möjligt, och att svara med avsiktligt fel HTTP-koder kan vara förvirrande för utvecklare och legitima klienter (detta är lite mindre problem för webbläsare, där användare ser faktiskt inte koder). På grund av detta skulle jag inte rekommendera det i ditt fall, men det är fortfarande en intressant idé.

Det kommer faktiskt inte att sakta ner en angripare något märkbart belopp, men kommer att göra att framtida utvecklare som arbetar på din plattform blir riktigt irriterade på dig. Det kan också orsaka att vissa fina funktioner i dina HTTP-förfrågningsbibliotek inte är så trevliga, eftersom de fungerar av felaktig information.

Detta är en mycket svag form av säkerhet genom dunkelhet. När du utformar ett system som detta bör du tänka på att sakta ner en angripare med hundratals år, inte tiotals minuter - annars kommer du fortfarande att förlora.

I stället för att returnera en "401 Obehörig", varför inte returnera t.ex. "305 Använd proxy", dvs avsiktligt vara förvirrande.

Ja, det kommer att förvirra en angripare. Men för en utbildad kan det inte vara mer än två sekunder platt. Och statuskoder är inte så användbara, huvudsakligen bara när man tvingar filnamn.

Säg att jag har en giltig nyckel och jag kan se att du returnerar 200-intervallkoder för min autentisering. Om jag ändrar lite i min nyckel, och för varje begäran du antingen returnerar 305s, kommer jag genast att tänka "Hmm. Verkar som att utvecklaren kanske har trasslat". Om du returnerar slumpmässiga koder vet jag att det var avsiktligt och jag ignorerar dem bara.

svårigheten med att omvända en iOS-app kommer förhoppningsvis att avskräcka alla utom de mest beslutsamma hackarna

Ja det kommer det, men eftersom det bara tar en att publicera det, saktar det bara ner igen ..

Detta är säkerhet genom dunkelhet, det vill säga det ger inte mycket säkerhet alls. Lösningen du föreslår kommer bara att sakta ner en angripare och inte hindra dem från att använda sin egen klient. Faktum är att din metod för att kryptera förfrågningarna, beroende på din implementering, faktiskt kan göra din applikation mindre säker genom att öppna upp attacker på andra delar av kryptosystemet. Din ansträngning skulle bättre spenderas för att försäkra sig om API-funktionerna själva (dvs. testa dem och säkra dem mot attacker som SQL-injektion), snarare än att försöka förhindra obehöriga klienter från att komma åt dem.

Men användaren använder redan ditt protokoll.

Ditt problem är att serverns gränssnitt för vad användaren kan göra inte är säkert!
Du bestäm vilka data din server skickar ut till vem!
(Hej kära onlinetidningar. Ja, jag tittar på dig!)

Designa det , förutsatt att användaren är klienten. Inte din kod. Eftersom han är det. Det borde inte ha någon roll vilken klient som används.
Din app körs på en CPU som är under maskinvarukontroll av användaren. Din kod är bara en lista med kommandon / data, och användaren och hans CPU kan bearbeta den hur som helst. Inkluderar inte bearbetar det.
Han bestämmer vad hans CPU gör. Missa inte hans nåd att acceptera din appkod som den är för en rätt till blind körning. Du är den som har litat på här, och det förtroendet är väldigt flyktigt.
Speciellt med sleazy-taktik som denna.

I vilket fall som helst: Du ger användaren krypteringsnyckeln och allt och förväntar honom att inte använda den själv, för du lägger den någonstans i din korg med kod. ... Precis som DRM är det ormolja och kan aldrig fungera.
Det tar bara en person att hitta var du sätter nyckeln. (Det skulle till exempel vara jag.) Alla andra måste bara google för det.

Men jag är förvånad över att du bara tänker på att kryptera protokollet mot användaren, istället för för hans skydd mot människa-i-mitten-attacker.
förutsatt att detta vanligtvis görs (Ja, jag pratar med dig "innehållsbranschen" igen.): Om din användare är din fiende, kanske du bör leta efter en affärsmodell som är baserad på rättvisa och vinn-vinn, istället för att slita bort användaren och behöva hantera motreaktioner.

PS: Ignorera alla ”säkerhet genom dunkelhet” svar. Detta är ett misstag som resulterar i korrekt beteende men som fortfarande bygger på ogiltiga antaganden. Att använda det som ett argument är i bästa fall amatörmässigt och inte riktigt kompetent.
I själva verket är all säkerhet genom dunkelhet. Vissa är bara mer dunkla (= bättre förklädda). Den verkliga anledningen till att detta är dåligt beror på att det vi kallar verklig säkerhet är en bazillion gånger mer obskyr, vilket ger en verklig (statistisk) pålitligt hög dunkel, i motsats till mycket enkel dunkel som bara är för troligt för någon att komma på från ingenting.

Som andra redan har förklarat, saktar säkerhet genom dunkelhet i bästa fall en angripare.

I ditt specifika fall skulle jag säga att det inte kommer att ha någon märkbar effekt. För att komma till denna punkt var din angripare redan tvungen att omvandla din app och extrahera den privata nyckeln. Det betyder att din angripare inte är en idiot och vet vad han gör. Lite dunkel kostar honom mindre tid än det tar dig att implementera den.

Som andra redan har nämnt föreslår du att du använder Security by Obscurity. Även om den här tekniken har sitt syfte, bör du överväga följande innan du väljer att använda detta tillvägagångssätt:

• Erbjuder teknisk support för ditt API. Att använda vilseledande HTTP-svarkoder gör det svårt för någon annan än dig att ge support. De måste överväga om den specifika situationen faktiskt skickar rätt svarkod eller om den skickar en obskyr. Bör du bestämma dig för att förbli den enda kontakten för eventuella supportförfrågningar, bör detta inte vara ett problem.
• Vad är en "skadlig användare"? Var försiktig när du kategoriserar en begäran som skadlig eftersom den kan ha negativa effekter. Antag att en IP är fast besluten att skicka skadlig trafik och motåtgärder används. Antag nu att samma IP faktiskt är en proxy med hundratals eller tusentals användare bakom sig. Du har nu tillämpat din motåtgärd på dem alla. Samma princip kan användas för att identifiera skadlig aktivitet i rubriker och / eller kropp.
• Applikationskoden är långsammast. Förfrågan måste gå igenom hela stacken för att äntligen komma till "säkerhets" -logiken. Denna arkitektur skalas inte bra och är långsam. Dåliga begäranden bör stoppas så tidigt som möjligt, vilket är förutsättningen för att använda Web Application Firewalls (WAF).
• Utöka åtkomsten. Om ditt API blir tillgängligt för fler klienter, var det ursprungligen designat för, de nya klienterna måste vara medvetna om möjlig användning av vilseledande HTTP-svarskoder.
• Ihållande skadliga användare. Som andra har nämnt är denna teknik bara en hastighetsstöt.

Bättre tillvägagångssätt

Fokusera din tid på vitlistning av alla kända bra förfrågningar. Detta är så mycket lättare än att försöka identifiera alla potentiella dåliga förfrågningar. Allt som inte visas på vitlistan bör omedelbart få en lämplig svarkod som HTTP 400 eller HTTP 405 om du filtrerar på HTTP-verb (som exempel). Detta händer helst innan begäran träffar din applikationskod.

Tillsammans med godkända förfrågningar om vitlistning, se till att din ansökan är skyddad baserat på OWASP-riktlinjer. Du får mycket bättre resultat spendera din tid med OWASP och försöker sedan avgöra vad en skadlig användare är och returnera en obskur HTTP-svarskod.

I grund och botten kan du INTE hindra obehöriga kunder från att skicka förfrågningar. Det närmaste möjliga skulle vara att få någon form av kryptografisk kontroll utförd hos klienten, men som Sherlock Holmes sa, "vad man kan uppfinna, kan en annan upptäcka". (Jag vet detta säkert, för jag har knäckt människors klientsäkerhetssäkerhet vid ett antal tillfällen.)

Bygg istället ditt API så att någon får använda det använder anpassade klienter. Gör det vänligt. Vad tappar du för det? Angripare kommer att attackera oavsett vad du gör, och om du gör ditt API lätt att använda kommer någon att komma med något du aldrig tänkt på och göra din server ännu större än du någonsin föreställt dig att det kunde vara. Vad kan göras av en klient som pratar med både ditt API och några andra? Vilka otaliga möjligheter finns det, och kommer det verkligen att skada dig att tillåta dem?

Jag skulle inte göra det. Det betyder i allmänhet att du skapar din egen standard, vilket får:

1. att ditt API är förutsägbart efter att du har gjort en karta över dina http-svar till deras faktiska betydelse. Att ändra HTTP-svar kan fungera på vissa "hackare" som skulle ge upp efter några försök, men det kommer inte att göra på andra, mer bestämda. Vill du skydda ditt API från endast tidigare typ, dvs. 11-åringar? Jag tror inte det.

2. en hel del förvirring för utvecklare och förmodligen testare, särskilt de som används för att fungera enligt globala standarder.

3. Välj något annat sätt. Det finns definitivt några. Jag har kämpat med samma headscratcher själv i några veckor nyligen och kom på minst två mer eller mindre tillförlitliga sätt att uppnå önskade begränsningar [kan dock inte lägga upp dem här].

ol >

Det finns definitivt bättre och MYCKET effektivare sätt att få det du vill ha. Försök att titta på ditt API från en annan vinkel ... Om du var en hackare och ditt liv var beroende av att hacka det API: t - vad skulle du göra för att lyckas? Vad ska hända för att du ska bli frustrerad i dina försök att bryta det?

En bra anledning att inte göra detta, särskilt för en mobilapp, är att det är mycket troligt att din app redan pratar med din server via flera proxyservrar, till exempel i telefonföretaget. De flesta stora företag använder proxyservrar i sitt nätverk för att försöka skydda sina system från skadligt innehåll, och många telefonföretag minskar kvaliteten på video eller bilder under transport. Det gör också att användningen av de olika systembiblioteken för HTTP på din plattform är värdelös för dig. Ett tillvägagångssätt som ofta används är att härleda någon nyckel eller token från information som det är osannolikt att användaren vill dela, till exempel hashing deras namnadress och kreditkortsinformation. På det här sättet, även om din app är hackad, kommer människor att vara försiktiga med att ge den information som krävs till ett slumpmässigt program som de laddade ner, vilket begränsar delningsförmågan för alla bevisade attacker.

Generellt sett är det ingen bra idé.

Jag använde detta mycket riktat en gång för att få en bra effekt när en kunds webbplats användes av en stulen kreditkortsvaskring. Det fanns några identifierande funktioner som bara delades av bedrägliga transaktioner så snarare än att hövligt vägra dem skulle jag få webbplatsen att fördröja svaret med några minuter (ingen gillar en webbplats som tar några minuter att göra något) och sedan returnera en 500 med webbplatsens standard "ledsen, det är inte du, det är jag" -meddelandet för serverfel (det loggade också information för att vidarebefordra till brottsbekämpning). Vi hade tre försök på transaktioner som fick detta spelande svar och sedan aldrig hört talas om dem igen.

Det var dock:

1. Som svar på något vi visste var en attack snarare än att vara motbjudande för användare som har problem.
2. Inte ett försvar mot en attack mot säkerheten i själva protokollet, utan på den mänskliga nivån ovanför.
3. Förklarligt genom andra förklaringar , dvs vi låtsades ha en riktigt sugig webbplats i en situation där det var troligt (det finns många sura webbplatser där ute) och vi var inte ett specifikt mål (perps skulle gå vidare till någon annan).

Användare som har problem ska hjälpas, inte missbrukas. "Jag kan inte göra det för att du inte är rätt auktoriserad" vägrar att göra något på ett bra sätt. "Jag kan inte göra det för att du måste använda en proxy" när någon inte behöver använda en proxy är kränkande. Att medvetet vara ohjälpsam är bara lämpligt när du vet att du attackeras och då ska det inte se ut som ett uppenbart falskt meddelande eller om du inte har dolt någonting (potentiellt har du faktiskt avslöjat något om samma falska status inte används för varje klientfel).

Med detta sagt är det lämpligt att vidta åtgärder för att status inte ska läcka information. T.ex. det är acceptabelt (beskrivs som sådant i standarderna) för / admin / till 404 men det skulle 200 i ett annat fall (auktoriserad användare, tillåtna klient-IP-adresser etc.) Alternativt om / medlemmar / min-profil kommer 200 för en auktoriserad användare och 403 eller 401 annars, om / medlemmar / fdsasafdasfwefaxc skulle 404 för en auktoriserad användare är det en bra idé att det till 403 eller 401 för den obehöriga användaren. Detta är inte så mycket säkerhet genom dunkel som att överväga vilka URI: er som relaterar till resurser som en av de bitar av information som skyddas.