Grunnleggende prinsipper
1. UCloud legger stor vekt på sikkerheten til sine produkter og virksomhet, og har alltid vært forpliktet til å sikre brukernes sikkerhet
Vi ser frem til å styrke UClouds nettverk gjennom Security Response Center ved å samarbeide tett med enkeltpersoner, organisasjoner og selskaper i bransjen
Sikkerhetsnivå.
2. UCloud Vi takker white hat-hackerne som hjalp til med å beskytte interessene til brukerne våre og bidro til å forbedre UCloud Security Center
Og å gi tilbake.
3. UCloud motsetter seg og fordømmer alle sårbarheter som bruker sårbarhetstesting som unnskyldning for å ødelegge og skade brukernes interesser
Hackingaktiviteter, inkludert, men ikke begrenset til, utnyttelse av sårbarheter for å stjele brukerinformasjon, invadere forretningssystemer, endre og stjele relatert informasjon
Enhetlige data, ondsinnet spredning av sårbarheter eller data. UCloud vil påta seg juridisk ansvar for noen av de ovennevnte handlingene.
Sårbarhetstilbakemelding og håndteringsprosess
1. Send inn sårbarhetsinformasjon via e-post, Weibo eller QQ-gruppe.
2. Innen én virkedag vil USRC-ansatte bekrefte mottak av sårbarhetsrapporten og følge opp for å begynne å vurdere problemet.
3. Innen tre virkedager vil USRC-ansatte ta opp saken, gi en konklusjon og sjekke tildelingen. (Om nødvendig vil det bli gitt.)
Reporteren kommuniserer og bekrefter, og ber reporteren om hjelp. ）
4. Forretningsavdelingen utbedrer sårbarheten og ordner oppdateringen slik at den legges på nett, og reparasjonstiden avhenger av problemets alvorlighetsgrad og hvor vanskelig det er å reparere.
5. Sårbarhetsrapportører gjennomgår sårbarheter.
6. Del ut belønninger.
Kriterier for poengsetting for sikkerhetssårbarheter
For hvert sårbarhetsnivå vil vi gjennomføre en omfattende undersøkelse basert på den tekniske vanskeligheten ved å utnytte sårbarheten og virkningen av sårbarheten
Vurdering, delt inn i ulike nivåer, og gitt tilsvarende poeng.
Avhengig av tjenestenivået for sårbarhet deles graden av sårbarhetsskade inn i fire nivåer: høy risiko, middels risiko, lav risiko og ignorert
Sårbarhetene som dekkes og poenggivningskriteriene er som følger:
Høy risiko:
Belønninger: Handlekort verdt 1000–2000 yuan eller gaver av samme verdi, inkludert, men ikke begrenset til:
1. En sårbarhet som direkte gir systemrettigheter (serverrettigheter, databaseprivilegier). Dette inkluderer, men er ikke begrenset til, fjerne, vilkårlige kommandoer
Kjøring, kodeutførelse, vilkårlig filoplasting for å få Webshell, buffer overflow, SQL-injeksjon for å få systemrettigheter
Begrensninger, serverparsing-sårbarheter, filinkluderingssårbarheter, osv.
2. Alvorlige logiske designfeil. Dette inkluderer, men er ikke begrenset til, å logge inn med hvilken som helst konto, endre passordet til en hvilken som helst konto, og verifisere SMS og e-post
Bypass.
3. Alvorlig lekkasje av sensitiv informasjon. Dette inkluderer, men er ikke begrenset til, seriøs SQL-injeksjon, vilkårlig filinkludering osv.
4. Uautorisert tilgang. Dette inkluderer, men er ikke begrenset til, å omgå autentisering for å få direkte tilgang til bakgrunnen, svak passord for bakgrunnsinnlogging, SSH-svakt passord, osv
Ifølge biblioteket er passordet svakt, osv.
5. Få tak i brukerens UCloud-brukerdata eller tillatelser via UCloud-plattformen.
Middels fare:
Belønninger: Handlekort eller gaver verdt 500-1000 yuan av samme verdi, inkludert, men ikke begrenset til:
1. Sårbarheter som krever interaksjon for å skaffe brukeridentitetsinformasjon. Inkludert lagringsbasert XSS, blant annet.
2. Vanlige logiske designfeil. Inkludert, men ikke begrenset til, ubegrenset SMS- og e-postutsendelse.
3. Ufokuserte produktlinjer, utnyttelse av vanskelige SQL-injeksjonssårbarheter, osv.
Lav risiko:
Belønninger: Handlekort verdt 100-500 yuan eller gaver av samme verdi, inkludert, men ikke begrenset til:
1. Generell sårbarhet for informasjonslekkasje. Dette inkluderer, men er ikke begrenset til, stilekkasje, SVN-fillekkasje, LOG-fillekkasje,
phpinfo, osv.
2. Sårbarheter som ikke kan utnyttes eller som er vanskelige å utnytte, inkludert, men ikke begrenset til, reflekterende XSS.
Ignorer:
Dette nivået inkluderer:
1. Feil som ikke involverer sikkerhetsproblemer. Inkludert, men ikke begrenset til, produktfunksjonsfeil, utydelige sider, stilblanding osv.
2. Sårbarheter som ikke kan gjenskapes, eller andre problemer som ikke kan reflekteres direkte. Dette inkluderer, men er ikke begrenset til, spørsmål som er rent brukerspekulative
Spørsmål.
Generelle prinsipper for poengkriterier:
1. Poenggivningskriteriene gjelder kun for alle UClouds produkter og tjenester. Domenenavn inkluderer, men er ikke begrenset til, *.ucloud.cn, servere
Inkluderer servere drevet av UCloud, og produktene er mobile produkter utgitt av UCloud.
2. Feilbelønninger er begrenset til sårbarheter sendt inn på UCloud Security Response Center, ikke de som sendes inn på andre plattformer
Poeng.
3. Innsending av sårbarheter som er offentliggjort på Internett vil ikke bli scoret.
4. Poeng for den tidligste committer med samme sårbarhet.
5. Flere sårbarheter fra samme sårbarhetskilde registreres som kun 1.
6. For samme lenke-URL, hvis flere parametere har lignende sårbarheter, vil samme lenke være forskjellig i henhold til én sårbarhetskreditt
type, vil belønningen bli gitt i henhold til graden av skade.
7. For generelle sårbarheter forårsaket av mobile terminalsystemer, som webkit uxss, kodekjøring osv., gis kun den første
Belønninger for sårbarhetsrapporterere vil ikke lenger telle for samme sårbarhetsrapport som andre produkter.
8. Den endelige poengsummen for hver sårbarhet bestemmes av en grundig vurdering av sårbarhetens utnyttbarhet, skadens størrelse og omfanget av påvirkningen. Det er mulig
Sårbarhetspunkter med lave sårbarhetsnivåer er høyere enn sårbarheter med høye sårbarhetsnivåer.
9. Hvite hatter bes om å oppgi POC/utnyttelse ved rapportering av sårbarheter og tilhøre sårbarhetsanalyse for å fremskynde administratorene
Behandlingshastigheten kan bli direkte påvirket for sårbarhetsinnsendelser som ikke leveres av POC-en eller utnyttelsen, eller som ikke analyseres i detalj
Belønninger.
Bonusutbetalingsprosess:
USRC-ansatte forhandlet med de hvite hattene når og hvordan gavene skulle deles ut.
Tvisteløsning:
Hvis rapportøren har innvendinger mot sårbarhetsvurderingen eller sårbarhetsvurderingen under sårbarhetshåndteringsprosessen, kontakt administratoren i tide
Kommunikasjon. UCloud Security Emergency Response Center vil ha forrang foran interessene til sårbarhetsrapportører, og vil gjøre det om nødvendig
Introdusere eksterne myndigheter for felles avgjørelse.
|
Publisert på 28.09.2015 00:14:33
|
|
|
