Rundt nyttår ble den årlige CCC-konferansen avholdt, og som vanlig ble det avdekket noen større sikkerhetssvakheter. Denne gangen var turen kommet til HashDOS. Dette er egentlig et gammelt problem (avdekket allerede i 2003) og gjelder Ruby on Rails, ASP.NET, java m.fl. En av få plattformer som ikke ble rammet var Perl, da de tok dette [...]
Cross site scripting (XSS) vulnerabilities are probably the most common security errors we as developers make. Security companies around the world report finding it in as many as 80 percent of the applications they asses. Why is this still a problem, and is it really all that dangerous?
Med Clickjacking utnytter en angriper at andre nettsider og plugins kan hentes inn og blandes med innholdet på angriperens nettside på en slik måte at brukere kan bli lurt til å utføre handlinger på andre sider de er logget inn på i samme nettlesersesjon. Her viser vi hvordan Clickjacking fungerer og hvordan du kan beskytte deg og dine brukere.
OWASP Top 10 prosjektet har rangert usikret kommunikasjon som nummer 9 basert på risiko. Svakheten innebærer at konfidensialitet og integritet av informasjon ikke er tilstrekkelig ivaretatt mellom server og klient.
Cross-site request forgery (CSRF) er et angrep der en angriper sender en forespørsel på vegne av en annen innlogget bruker. Angriperen har da mulighet til å utføre de handlingene som brukeren har rettigheter til i webapplikasjonen. Her viser vi hvordan du kan sikre din webapplikasjoner mot CSRF.
Cross-Site Scripting (XSS) svakheter er en av de vanligste sikkerhetsfeilene i webapplikasjoner. XSS er rangert som nummer 2 i OWASP top 10, rett etter injection-feil. Svakheten kan oppstå alle steder der bruker-input presenteres tilbake til brukerene uten at det valideres eller escapes. Ved å utnytte slike svakheter, kan en angriper stjele vilkårlige data, brukernavn, passord, [...]
Hvis man tar en titt på OWASP Top 10 2010, som ifølge OWASP var de mest kritiske sikkerhetsrisikoene i webapplikasjoner i år 2010, finner man injeksjonsangrep på toppen. Dette skyldes at injeksjonsårbarheter dessverre fortsatt er vanlig å finne i webapplikasjoner. I tillegg er de er ofte enkle å utnytte og et vellykket injeksjonsangrep kan ha [...]
De kommende månedene legger vi i BEKKs sikkerhetsgruppe ut en serie innlegg om sikkerhet i webapplikasjoner. Følg med på BEKK Open for mer!
Når man lager sikker og robust programvare er det ofte en utfordring å teste applikasjonen under utvikling. Man lager derfor såkalte bakdører for å slå av, eller omgå, sikkerhet. Dette kan være nyttig og tidsbesparende for utviklere og testere mens man utvikler eller tester det man utvikler. Men, det er imperativt at ikke slik kode blir med ut i produksjon på en måte som gjør at utenforstående kan utnytte disse bakdørene for “ondsinnede” angrep. Ofte ser man teknikker hvor utviklere gjør det vanskelig for utenforstående å finne eller aktivere disse bakdørene, men det tryggeste, og etter min mening det eneste riktige, er å utelate slik kode i produksjon.
Av Stein Inge Morisbak
|
|
Merket som back door, build-helper-maven-plugin, filteringDeploymentDescriptors, java, Jetty, maven, Maven-jetty-plugin, maven-war-plugin, maven2, maven3, packagingExcludes, profile, programvareutvikling, web.xml, webdefault.xml
|
De siste årene har vi sett flere massive SQL-injection- og Cross Site Scripting (XSS)-angrep mot store siter. Twitter hadde nylig en XSS-feil og i begynnelsen av juni var det et stort angrep mot siter som kjørte en bestemt annonsekomponent. Beskyttelse mot denne type angrep, krever at man tenker på kontekst når man skriver kode. Validering [...]
