چگونه می توانم اثبات مفهوم ( poc ) ایجاد کنم؟

دسته بندی :بلاگ 1 آوریل 2020 علیرضا 1853

من یک راز برای شما دارم که نحوه اثبات مفهوم ( poc ) خودم را شرح می دهم: از قوانین کلاه سفیدها پیروی کنید و سپس با این حساب ، برای ایجاد مفهوم ( poc ) نوشتن تفکر خود را به کلاه سیاه ها تغییر دهید. منظور من از این امر این است که همیشه در هنگام شکار باگ از قوانین پیروی کنید و بعد از آنکه آسیب پذیری مسئله اثبات شد، poc خود را به گونه ای ایجاد کنید که جلب توجه کند ( کمی بزرگ نمایی ) چگونه یافته شما به طور بالقوه می تواند روی هدف تأثیر بگذارد و به آن آسیب بزند. این حرف قطعاً به معنی این نیست که شما باید شروع به تشدید مسئله و دستیابی به دسترسی های غیرمجاز کنید. شما باید درک کنید که تأثیر بالقوه واقعی یافته شما چیست و سپس طبق قوانین برنامه باگ بانتی کار کنید تا چیزی واقعاً ایجاد کنید که در یک سناریوی دنیای واقعی کار کند. در این گزارش می توانید این طرز فکر را در عمل مشاهده کنید.

Hall of PoC

این یک لیست بزرگ برای اثبات مفاهیم (PoC) است که می توانید هنگام اثبات تأثیر مسئله خود از آنها استفاده کنید. PoC ها به گونه ای طراحی شده اند که برنامه bug bounty می تواند به سرعت مسئله را درک کند و اطمینان حاصل کند که به هیچ یک از کاربران یا خدمات آنها در این روند آسیب نمی رساند. گفته می شود ، همیشه قوانین سیاست برنامه را دنبال کنید. سیاست امنیتی برنامه همیشه از اولویت لیست برخوردار است.

Issue type	PoC
Cross-site scripting	`alert(document.domain)` or setInterval`alert\x28document.domain\x29` if you have to use backticks.^[1] Using `document.domain` instead of `alert(1)` can help avoid reporting XSS bugs in sandbox domains, as described on the Google Bughunter University site.
Command execution	This involves the execution of arbitrary commands on a target server. Check the program security policy as specific commands may be designated for testing. For example, this set of primitives is set by Yahoo to ensure researchers “minimise the mayhem.” Read (Linux-based): `cat /proc/1/maps` Write (Linux-based): `touch /root/your_username` Execute (Linux-based): `id`
Code execution	This involves the manipulation of a web app such that server-side code (e.g. PHP) is executed. PHP: `<?php echo 7*7; ?>`
SQL injection	If column values can be influenced, simply grabbing the SQL server version with the following payloads should be enough to demonstrate basic SQL injection capability. MySQL and MSSQL: `SELECT @@version` Oracle: `SELECT version FROM v$instance;` Postgres SQL: `SELECT version()`
Unvalidated redirect	Set the redirect endpoint to a known safe domain (e.g. `google.com`), or if looking to demonstrate potential impact, to your own website with an example login screen resembling the target’s. Ensure that your proof of concept page is static, described as a proof of concept, and does not really send credentials anywhere. If the target uses OAuth, you can try to leak the OAuth token to your server to maximise impact. ^[2]
Information exposure	Data exposure manifests in a variety of forms. Researchers should use self-created test accounts (or those provisioned by the program you’re working on). Let’s say you’re looking for an IDOR vulnerability — which in this example is an endpoint allowing you to iterate over an ID parameter (e.g. `?id=1337`) to disclose another user’s information. Investigate only with the IDs of your own test accounts — do not leverage the issue against other users’ data — and describe your full reproduction process in the report.
Cross-site request forgery	After you’ve confirmed the presence of a CSRF bug — ensuring there are no leftover token or once-only values — either attach a file to demonstrate your proof of concept or paste the code in a code block in your report. `<form action="http://example.com/settings" method="POST"> <input type="hidden" name="username" value="example"/> <input type="hidden" name="password" value="password1234"/> <input type="submit" value="Click me"/> </form>` When designing a real-world example, either hide the form (`style="display:none;"`) and make it submit automatically, or design it so that it resembles a component from the target’s page.
Server-side request forgery	The “How To” article from HackerOne is an excellent introduction to SSRF. As Jobert explains, webhooks, parsers, and PDF generator features are often vulnerable. The impact of a SSRF bug will vary — a non-exhaustive list of proof of concepts includes: reading local files obtaining cloud instance metadata making requests to internal services (e.g. Redis) accessing firewalled databases
Local and remote file inclusion	Local inclusion allows you to. Remote inclusion allows you to.
Local file read	این تنها به شما امکان می دهد پرونده هایی را که در سیستم هدف قرار دارند ، بخوانید. اطمینان حاصل کنید که فقط یک پرونده بی ضرر را بازیابی کنید. خط مشی امنیتی برنامه را بررسی کنید زیرا ممکن است یک پرونده خاص برای آزمایش تعیین شود.
XML external entity processing	Output random harmless data. ^[3] `<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>`
Sub-domain takeover	laim the sub-domain discreetly and serve a harmless file on a hidden page. Do not serve content on the index page.

برچسب‌ها:;ghi stdn, bug bounty hunter, Bug bounty چیست, fh', fh' fhkjd, fh' naj, foo, food, poc, v, vh, آزمون نفوذ, اثبات مفهوم, باگ بانتی, باگ بانتی‌ ایران, باگ باونتی, باگ هاب, برنامه باگ بانتی, ترفند, تست نفوذ, رخنه, فضل اشکال, کلاه سفید, نفوذ, نکات, هکر

علیرضا

تاریخ عضویت:3 دسامبر 2018

راه آسان‌تری برای ارتباط با کاربران‌مان پیدا کرده‌ایم :) عضویت در کانال

مطالب زیر را حتما بخوانید:

قوانین ارسال دیدگاه در سایت

چنانچه دیدگاهی توهین آمیز باشد و متوجه اشخاص مدیر، نویسندگان و سایر کاربران باشد تایید نخواهد شد.
چنانچه دیدگاه شما جنبه ی تبلیغاتی داشته باشد تایید نخواهد شد.
چنانچه از لینک سایر وبسایت ها و یا وبسایت خود در دیدگاه استفاده کرده باشید تایید نخواهد شد.
چنانچه در دیدگاه خود از شماره تماس، ایمیل و آیدی تلگرام استفاده کرده باشید تایید نخواهد شد.
چنانچه دیدگاهی بی ارتباط با موضوع آموزش مطرح شود تایید نخواهد شد.

لینک کوتاه:

چگونه می توانم اثبات مفهوم ( poc ) ایجاد کنم؟

Hall of PoC

مطالب زیر را حتما بخوانید:

قوانین ارسال دیدگاه در سایت

کاربران

خدمات مشتریان

مرکز تماس مشتریان