WORKSECTION

Vulnerability Disclosure Policy

Intro

This Vul­ner­a­bil­i­ty Dis­clo­sure Pol­i­cy (VDP) applies to any vul­ner­a­bil­i­ties you con­sid­er report­ing to Work­sec­tion. Please read this VDP ful­ly before you report a vul­ner­a­bil­i­ty, and always act in com­pli­ance with it.

We high­ly appre­ci­ate indi­vid­u­als who ded­i­cate their time and efforts to respon­si­bly dis­close secu­ri­ty vul­ner­a­bil­i­ties in accor­dance with this pol­i­cy. We appre­ci­ate researchers assist­ing us in our secu­ri­ty efforts and extend our grat­i­tude in advance for your sub­mis­sion and discretion. 

Your test­ing must not vio­late any law or dis­rupt or com­pro­mise any data that is not your own. If you find a poten­tial vul­ner­a­bil­i­ty that allows access to restrict­ed data or resources, you should noti­fy us imme­di­ate­ly — do not con­tin­ue to inves­ti­gate the vul­ner­a­bil­i­ty yourself.

Scope

This pol­i­cy applies to the fol­low­ing domain: https://​work​sec​tion​.com/ 

Guid­ance

While we high­ly encour­age respon­si­ble vul­ner­a­bil­i­ty dis­cov­ery and report­ing, cer­tain actions are strict­ly pro­hib­it­ed. Please refrain from engag­ing in the fol­low­ing activities:
  • Per­form­ing actions that may have a neg­a­tive impact on the Com­pa­ny or its users, such as spam­ming, con­duct­ing brute force attacks, or launch­ing Denial of Ser­vice attacks. Sim­i­lar­ly, avoid any tests that may impair sys­tem access or cause dam­age to data.
  • Access­ing or attempt­ing to access any data or infor­ma­tion that does not belong to you. It is impor­tant to respect the bound­aries of autho­rized access.
  • Destroy­ing, cor­rupt­ing, or attempt­ing to destroy or cor­rupt any data or infor­ma­tion that does not belong to you. Safe­guard the integri­ty and con­fi­den­tial­i­ty of data.
  • Uti­liz­ing high-inten­si­ty inva­sive or destruc­tive scan­ning tools for the pur­pose of iden­ti­fy­ing vul­ner­a­bil­i­ties. Such tools should not be employed as they may cause undue disruption.
  • Engag­ing in phys­i­cal test­ing, includ­ing attempt­ing office access, exploit­ing open doors, or tail­gat­ing. Social engi­neer­ing tech­niques, such as phish­ing or vish­ing, are also pro­hib­it­ed. Focus sole­ly on tech­ni­cal vul­ner­a­bil­i­ty testing.
  • Con­duct­ing social engi­neer­ing activ­i­ties tar­get­ing the Company’s team mem­bers, con­trac­tors, or users. Respect the pri­va­cy and trust of indi­vid­u­als asso­ci­at­ed with our organization.
  • Vio­lat­ing any laws or breach­ing agree­ments in your pur­suit of dis­cov­er­ing vul­ner­a­bil­i­ties. Adhere to legal and eth­i­cal bound­aries through­out the process.
By adher­ing to these guide­lines, you ensure that your vul­ner­a­bil­i­ty dis­cov­ery activ­i­ties are con­duct­ed in a respon­si­ble and law­ful manner.

Exclu­sions from the scope

The fol­low­ing find­ings are specif­i­cal­ly non-reward­able with­in this program:
  • Dis­clo­sure of known pub­lic files or direc­to­ries (e.g., robots.txt)
  • Click­jack­ing and cer­tain issues only exploitable through clickjacking
  • Logout Cross-Site Request Forgery (logout CSRF)
  • Weak captcha
  • Lack of Secure and HTTPOn­ly cook­ie flags
  • Mis­con­fig­ured or lack of SPF/DKIM records
  • Lack of SSL/TLS best practices
  • DDoS vul­ner­a­bil­i­ties
  • Miss­ing HTTP secu­ri­ty head­ers, e.g.: Strict-Trans­port-Secu­ri­ty, X‑Frame-Options, X‑XSS-Pro­tec­tion, X‑Con­tent-Type-Options, Con­tent-Secu­ri­ty-Pol­i­cy, X‑Con­tent-Secu­ri­ty-Pol­i­cy, X‑We­bKit-CSP, Content-Security-Policy-Report-Only
  • Out-of-date soft­ware versions
  • Vul­ner­a­bil­i­ties affect­ing users of out­dat­ed browsers or platforms
  • Social engi­neer­ing, phish­ing, phys­i­cal, or oth­er fraud­u­lent activities
  • Self-XSS that can­not be used to exploit oth­er users
  • Vul­ner­a­bil­i­ties in third-par­ty components
  • Bugs that require exceed­ing­ly unlike­ly user interaction
  • Con­tent spoof­ing and text injec­tion issues with­out a real attack vec­tor and/​or with­out being able to mod­i­fy HTML
  • Sub­do­main takeover with­out a proof of concept
  • Domain squat­ting or any oth­er domain speculations
  • Vul­ner­a­bil­i­ties that require phys­i­cal access to a user’s device
  • Vul­ner­a­bil­i­ty reports that are gen­er­at­ed by scan­ners or any auto­mat­ed or active exploit tools
  • Vul­ner­a­bil­i­ties involv­ing active con­tent, such as web brows­er add-ons
  • Denial of ser­vice (DoS/​DDoS) and spam­ming (SMS, email, etc.)
  • Most brute-forc­ing issues with­out any clear impact
  • Pub­licly acces­si­ble login pan­els with­out proof of exploitation
  • Dis­clo­sure of pub­lic user infor­ma­tion, as well as non-sen­si­tive and mod­er­ate­ly sen­si­tive information

Report­ing a vulnerability

If you have dis­cov­ered a poten­tial secu­ri­ty vul­ner­a­bil­i­ty on our plat­form, we kind­ly request that you report it direct­ly to the Company’s secu­ri­ty team via email at security@​worksection.​ua. This ensures that your report reach­es us prompt­ly, enabling us to respond more effec­tive­ly. Please refrain from send­ing the report to our gen­er­al email address or through the sup­port chat.

To main­tain the con­fi­den­tial­i­ty of the vul­ner­a­bil­i­ty, we ask that you avoid fil­ing a pub­lic issue or dis­cussing it on social media plat­forms such as Twit­ter or GitHub. We appre­ci­ate your coop­er­a­tion in keep­ing the com­mu­ni­ca­tion regard­ing the vul­ner­a­bil­i­ty con­fi­den­tial between you and our team. Please refrain from shar­ing your reports or any evi­dence with oth­er users or companies.

When sub­mit­ting a vul­ner­a­bil­i­ty report, please ensure that it includes the fol­low­ing essen­tial information:
  • Clear and rel­e­vant title. Pro­vide a con­cise and descrip­tive title that accu­rate­ly reflects the nature of the vulnerability.
  • Affect­ed service/​API. Clear­ly indi­cate the spe­cif­ic ser­vice or API that is affect­ed by the vul­ner­a­bil­i­ty. This helps us to quick­ly under­stand the scope of the issue.
  • Vul­ner­a­bil­i­ty details and impact. Thor­ough­ly explain the vul­ner­a­bil­i­ty, includ­ing its tech­ni­cal details and poten­tial impact on our sys­tems or users. Pro­vide suf­fi­cient infor­ma­tion to help us under­stand the nature and sever­i­ty of the vulnerability.
  • Steps to repro­duce / Proof of Con­cept. Include detailed instruc­tions on how to repro­duce the vul­ner­a­bil­i­ty, prefer­ably accom­pa­nied by a Proof of Con­cept (PoC). The PoC can be in var­i­ous forms such as a video demon­stra­tion, screen­shots from tools like Burp Suite, curl com­mands, or rel­e­vant code snip­pets. These mate­ri­als help us ver­i­fy and under­stand the vul­ner­a­bil­i­ty better.
  • Any oth­er impor­tant details. Feel free to include any addi­tion­al infor­ma­tion that you believe is rel­e­vant or help­ful for our under­stand­ing of the vul­ner­a­bil­i­ty. This can include sys­tem con­fig­u­ra­tions, rel­e­vant logs, or any oth­er sup­port­ing doc­u­men­ta­tion that can aid in the res­o­lu­tion process.
By pro­vid­ing a com­pre­hen­sive report that includes these ele­ments, you great­ly assist us in effi­cient­ly assess­ing and address­ing the report­ed vulnerability.

What hap­pens after report­ing a vulnerability

After you have sub­mit­ted your report, we will ana­lyze it in terms of impact, sever­i­ty, and exploita­tion com­plex­i­ty. If we con­sid­er it rel­e­vant, we will respond to you with­in fif­teen (15) work­ing days. We will keep you informed of our progress.

Once the report­ed vul­ner­a­bil­i­ty is reme­di­at­ed, we will noti­fy you, and you may be invit­ed to con­firm that the solu­tion ade­quate­ly cov­ers the vul­ner­a­bil­i­ty. We wel­come requests to dis­close your report once your vul­ner­a­bil­i­ty has been resolved. How­ev­er, please refrain from shar­ing infor­ma­tion about any dis­cov­ered vul­ner­a­bil­i­ties for 90 cal­en­dar days after receiv­ing our con­fir­ma­tion of receiv­ing your report.

Rewards

We typ­i­cal­ly do not offer any cash rewards for sub­mis­sions. How­ev­er, we might make an excep­tion in the case of valid crit­i­cal bugs and high-qual­i­ty reports. The reward amount will be deter­mined based on the max­i­mum impact of the vul­ner­a­bil­i­ty. Reports that are well-writ­ten and deemed use­ful have a greater chance of being con­sid­ered for a reward.

Please note that only the first indi­vid­ual to report a pre­vi­ous­ly unknown flaw will qual­i­fy for a reward.

User Agreement

. . . .

Data Processing Addendum (DPA)

. . . .

List of sub-processors

. . . .

Cookie Policy

. . . .

Privacy Policy

. . . .

Partnership Agreement

. . . .

Referral Agreement

. . . .