Translation

(itstool) path: para/indexterm
<primary>von Neumann</primary>
30/300
Context English Persian State
Brian Harvey and Matthew Wright <emphasis>Simply Scheme</emphasis> MIT 1994. ISBN 0-262-08226-8
Brian Harvey and Matthew Wright <emphasis>Simply Scheme</emphasis> MIT 1994. ISBN 0-262-08226-8
Randall Schwartz <emphasis>Learning Perl</emphasis> O'Reilly 1993 ISBN 1-56592-042-2
Randall Schwartz <emphasis>Learning Perl</emphasis> O'Reilly 1993 ISBN 1-56592-042-2
Patrick Henry Winston and Berthold Klaus Paul Horn <emphasis>Lisp (3rd Edition)</emphasis> Addison-Wesley 1989 ISBN 0-201-08319-1
Patrick Henry Winston and Berthold Klaus Paul Horn <emphasis>Lisp (3rd Edition)</emphasis> Addison-Wesley 1989 ISBN 0-201-08319-1
Brian W. Kernighan and Rob Pike <emphasis>The Unix Programming Environment</emphasis> Prentice-Hall 1984 ISBN 0-13-937681-X
Brian W. Kernighan and Rob Pike <emphasis>The Unix Programming Environment</emphasis> Prentice-Hall 1984 ISBN 0-13-937681-X
Brian W. Kernighan and Dennis M. Ritchie <emphasis>The C Programming Language (2nd Edition)</emphasis> Prentice-Hall 1988 ISBN 0-13-110362-8
Brian W. Kernighan and Dennis M. Ritchie <emphasis>The C Programming Language (2nd Edition)</emphasis> Prentice-Hall 1988 ISBN 0-13-110362-8
Bjarne Stroustrup <emphasis>The C++ Programming Language</emphasis> Addison-Wesley 1991 ISBN 0-201-53992-6
Bjarne Stroustrup <emphasis>The C++ Programming Language</emphasis> Addison-Wesley 1991 ISBN 0-201-53992-6
W. Richard Stevens <emphasis>Advanced Programming in the Unix Environment</emphasis> Addison-Wesley 1992 ISBN 0-201-56317-7
W. Richard Stevens <emphasis>Advanced Programming in the Unix Environment</emphasis> Addison-Wesley 1992 ISBN 0-201-56317-7
W. Richard Stevens <emphasis>Unix Network Programming</emphasis> Prentice-Hall 1990 ISBN 0-13-949876-1
W. Richard Stevens <emphasis>Unix Network Programming</emphasis> Prentice-Hall 1990 ISBN 0-13-949876-1
Secure Programming
برنامه‌نویسی ایمن
This chapter describes some of the security issues that have plagued <trademark class="registered">UNIX</trademark> programmers for decades and some of the new tools available to help programmers avoid writing exploitable code.
این فصل به تشریح برخی از مسائل امنیتی که برنامه‌نویسانِ <trademark class="registered">UNIX</trademark> را برای دهه‌ها گرفتار خود کرده است و همچنین به برخی از ابزارهای جدید که برای کمک به برنامه‌نویسان جهت اجتناب از نوشتن کدهای قابل بهره‌برداری در دسترس است می‌پردازد.
Secure Design Methodology
روش‌شناسی طراحی ایمن
Writing secure applications takes a very scrutinous and pessimistic outlook on life. Applications should be run with the principle of <quote>least privilege</quote> so that no process is ever running with more than the bare minimum access that it needs to accomplish its function. Previously tested code should be reused whenever possible to avoid common mistakes that others may have already fixed.
نوشتن برنامه‌های ایمن نیازمند نظرگاهی بسیار دقیق و بدبینانه نسبت به زندگی است. برنامه‌ها باید با اصل <quote>کمترین امتیاز</quote> اجرا شوند تا هیچ فرآیندی با بیش از حداقل دسترسی که برای دستیابی به کارکرد خود نیاز دارد اجرا نشود. کدهای از پیش آزموده شده باید هرزمان که ممکن بود مجدداً مورد استفاده قرار گیرند تا از اشتباهات رایجی که دیگران احتمالاً از پیش رفع کرده‌اند اجتناب شود.
One of the pitfalls of the <trademark class="registered">UNIX</trademark> environment is how easy it is to make assumptions about the sanity of the environment. Applications should never trust user input (in all its forms), system resources, inter-process communication, or the timing of events. <trademark class="registered">UNIX</trademark> processes do not execute synchronously so logical operations are rarely atomic.
یکی از مشکلات موجود در محیط <trademark class="registered">UNIX</trademark> سادگی در گمانه‌زنی پیرامون پایداری محیط است. برنامه‌ها هرگز نباید به ورودی کاربر (در تمام اشکال خود)، منابع سامانه، ارتباط بین پردازشی، یا زمانبندی رویدادها اعتماد کنند. فرآیندهای <trademark class="registered">UNIX</trademark> به‌طور همزمان اجرا نمی‌شوند، از این رو عملیات منطقی به‌ندرت اتمی هستند.
Buffer Overflows
سرریز میان‌گیر
<primary>buffer overflow</primary>
<primary>سرریز میان‌گیر</primary>
<primary>von Neumann</primary>
<primary>von Neumann</primary>
<primary>Morris Internet worm</primary>
<primary>کرم اینترنتی موریس</primary>
Buffer Overflows have been around since the very beginnings of the von Neumann <xref linkend="COD"/> architecture. <_:indexterm-1/> <_:indexterm-2/> They first gained widespread notoriety in 1988 with the Morris Internet worm. Unfortunately, the same basic attack remains <_:indexterm-3/> effective today. By far the most common type of buffer overflow attack is based on corrupting the stack.
سرریز میان‌گیر از ابتدای معماری فون نویمان <xref linkend="COD"/> بوده است. <_:indexterm-1/> <_:indexterm-2/> آنها برای اولین بار در سال ۱۹۸۸ با کرم اینترنتی موریس به‌طور گسترده بدنام شدند. شوربختانه، همان حملهٔ ابتدایی تا به امروز <_:indexterm-3/> مؤثر مانده است. تاکنون رایج‌ترین حملاتِ سرریز همگردان بر مبنای خراب‌کردن پشته بوده است.
<primary>stack</primary>
<primary>پشته</primary>
<primary>arguments</primary>
<primary>براهین</primary>
<primary>LIFO</primary>
<primary>LIFO</primary>
<primary>process image</primary> <secondary>stack pointer</secondary>
<primary>تصویر پردازش</primary> <secondary>اشاره‌گر پشته</secondary>
<primary>stack frame</primary>
<primary>چارچوب پشته</primary>
<primary>stack pointer</primary>
<primary>اشاره‌گر پشته</primary>
<primary>frame pointer</primary>
<primary>اشاره‌گر چارچوب</primary>
<primary>process image</primary> <secondary>frame pointer</secondary>
<primary>تصویر پردازش</primary> <secondary>اشاره‌گر چارچوب</secondary>
<primary>return address</primary>
<primary>نشانی بازگشت</primary>
<primary>stack-overflow</primary>
<primary>سرریز پشته</primary>
Most modern computer systems use a stack to pass arguments to procedures and to store local variables. A stack is a last in first out (LIFO) buffer in the high memory area of a process image. When a program invokes a function a new "stack frame" is <_:indexterm-1/> <_:indexterm-2/> created. This stack frame consists of the arguments passed to the function as well as a dynamic amount of local variable space. The "stack pointer" is a register that holds the current <_:indexterm-3/> <_:indexterm-4/> location of the top of the stack. Since this value is constantly changing as new values are pushed onto the top of the stack, many implementations also provide a "frame pointer" that is located near the beginning of a stack frame so that local variables can more easily be addressed relative to this value. <xref linkend="COD"/> The return address for function <_:indexterm-5/> <_:indexterm-6/> <_:indexterm-7/> <_:indexterm-8/> calls is also stored on the stack, and this is the cause of stack-overflow exploits since overflowing a local variable in a function can overwrite the return address of that function, potentially allowing a malicious user to execute any code he or she wants.
بیشتر رایانه‌های امروزی از پشته برای تحویل براهین به رویه‌ها و نگه‌داشت متغیرهای محلی استفاده می‌کنند. پشته یک میانگیر آخرین ورودی اولین خروجی در بخش بالایی حافظهٔ یک تصویر پردازش است. زمانی که یک برنامه تابعی را فراخوانی می‌کند، یک "قاب پشته" جدید <_:indexterm-1/> <_:indexterm-2/> ساخته می‌شود. این "قاب پشته" یک ثبات (register) است که موقعیت فعلی <_:indexterm-3/> <_:indexterm-4/> بالای پشته را نگه می‌دارد. از آنجا که این مقدار به‌طور مداوم به‌محض گذاشته شدن مقادیر در بالای پشته در حال تغییر است، بسیاری از پیاده‌سازی‌ها یک "نشانی قاب" ارائه می‌دهند که کنار بخش آغازین قاب پشته قرار می‌گیرد، که مقادیر محلی با سهولت بیشتر به‌واسطه این مقدار می‌توانند مورد خطاب قرار گیرند. <xref linkend="COD"/> نشانی بازگشتی درخواست‌های تابع <_:indexterm-5/> <_:indexterm-6/> <_:indexterm-7/> <_:indexterm-8/> نیز در پشته نگه داشته می‌شود، و این می‌تواند دلیل بهره‌جوهای سرریز پشته باشد، چرا که سرریز کردن یک متغیر محلی در یک تابع می‌تواند نشانی آن تابع را بازنویسی کند، که این امر بالقوه به یک کاربر بد اندیش اجازهٔ اجرای هر کدی که بخواهد را می‌دهد.
Although stack-based attacks are by far the most common, it would also be possible to overrun the stack with a heap-based (malloc/free) attack.
گرچه حملات مبتنی بر پشته با اختلاف رایج‌ترین آنها هستند، اما سرریز کردن پشته از طریق حملهٔ مبتنی بر هیپ (malloc/free) نیز ممکن است.
The C programming language does not perform automatic bounds checking on arrays or pointers as many other languages do. In addition, the standard C library is filled with a handful of very dangerous functions.
زبان برنامه‌نویسی C به‌طور خودکار بررسی حدود را بر روی آرایه‌ها یا اشاره‌گرها چنانکه بسیاری از زبان‌ها انجام می‌دهند، انجام نمی‌دهد. همچنین، کتابخانهٔ استاندارد C پر است از تعداد انگشت‌شماری از توابع بسیار خطرناک.

Loading…

<primary>von Neumann</primary>
<primary>von Neumann</primary>
a month ago
Browse all component changes

Things to check

Unchanged translation

Source and translation are identical

Reset

Glossary

English Persian
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: para/indexterm
Labels
No labels currently set.
Source string location
book.translate.xml:2995
Source string age
2 months ago
Translation file
books/fa/developers-handbook.po, string 474