欢迎来到麦多课文档分享! | 帮助中心 海量文档,免费浏览,给你所需,享你所想!
麦多课文档分享
全部分类
  • 标准规范>
  • 教学课件>
  • 考试资料>
  • 办公文档>
  • 学术论文>
  • 行业资料>
  • 易语言源码>
  • ImageVerifierCode 换一换
    首页 麦多课文档分享 > 资源分类 > PDF文档下载
    分享到微信 分享到微博 分享到QQ空间

    ISO IEC TS 17961-2013 Information technology - Programming languages their environments and system software interfaces - C secure coding rules《信息技术 程序设计语言 环境和系统.pdf

    • 资源ID:1257457       资源大小:1,022KB        全文页数:92页
    • 资源格式: PDF        下载积分:10000积分
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    二维码
    微信扫一扫登录
    下载资源需要10000积分(如需开发票,请勿充值!)
    邮箱/手机:
    温馨提示:
    如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如需开发票,请勿充值!如填写123,账号就是123,密码也是123。
    支付方式: 支付宝扫码支付    微信扫码支付   
    验证码:   换一换

    加入VIP,交流精品资源
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    ISO IEC TS 17961-2013 Information technology - Programming languages their environments and system software interfaces - C secure coding rules《信息技术 程序设计语言 环境和系统.pdf

    1、 ISO/IEC 2013 Information technology Programming languages, their environments and system software interfaces C secure coding rules Technologies de linformation Langages de programmation, leur environnement et interfaces des logiciels de systmes Rgles de programmation scurise en C ISO/IEC TS 17961 F

    2、irst edition 2013-11-15 Reference number ISO/IEC TS 17961:2013(E) TECHNICAL SPECIFICATION ISO/IEC TS 17961:2013(E)ii ISO/IEC 2013 All rights reserved COPYRIGHT PROTECTED DOCUMENT ISO/IEC 2013 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized o

    3、therwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright off

    4、ice Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ISO/IEC TS 17961:2013(E) ISO/IEC 2013 All rights reserved iii Contents Page Foreword v Introduction vi 1 Scope . 1 2 Conformance . 1 2.1 Portability ass

    5、umptions 2 3 Normative references 2 4 T erms and definitions . 2 5 Rules 5 5.1 Accessing an object through a pointer to an incompatible type ptrcomp . 5 5.2 Accessing freed memory accfree . 6 5.3 Accessing shared objects in signal handlers accsig . 7 5.4 No assignment in conditional expressions bool

    6、asgn . 8 5.5 Calling functions in the C Standard Library other than abort, _Exit, and signal from within a signal handler asyncsig 9 5.6 Calling functions with incorrect arguments argcomp .11 5.7 Calling signal from interruptible signal handlers sigcall 12 5.8 Calling system syscall .13 5.9 Comparis

    7、on of padding data padcomp .14 5.10 Converting a pointer to integer or integer to pointer intptrconv 14 5.11 Converting pointer values to more strictly aligned pointer types alignconv .15 5.12 Copying a FILE object filecpy 16 5.13 Declaring the same function or object in incompatible ways funcdecl .

    8、16 5.14 Dereferencing an out-of-domain pointer nullref .18 5.15 Escaping of the address of an automatic object addrescape 18 5.16 Conversion of signed characters to wider integer types before a check for EOF signconv .19 5.17 Use of an implied default in a switch statement swtchdflt .19 5.18 Failing

    9、 to close files or free dynamic memory when they are no longer needed fileclose .20 5.19 Failing to detect and handle standard library errors liberr 20 5.20 Forming invalid pointers by library function libptr .26 5.21 Allocating insufficient memory insufmem.28 5.22 Forming or using out-of-bounds poi

    10、nters or array subscripts invptr .29 5.23 Freeing memory multiple times dblfree 34 5.24 Including tainted or out-of-domain input in a format string usrfmt.35 5.25 Incorrectly setting and using errno inverrno 37 5.26 Integer division errors diverr .39 5.27 Interleaving stream inputs and outputs witho

    11、ut a flush or positioning call ioileave .40 5.28 Modifying string literals strmod .41 5.29 Modifying the string returned by getenv, localeconv, setlocale, and strerror libmod 42 5.30 Overflowing signed integers intoflow 43 5.31 Passing a non-null-terminated character sequence to a library function t

    12、hat expects a string nonnullcs 44 5.32 Passing arguments to character-handling functions that are not representable as unsigned char chrsgnext .45 5.33 Passing pointers into the same object as arguments to different restrict-qualified parameters restrict 46 5.34 Reallocating or freeing memory that w

    13、as not dynamically allocated xfree 47 5.35 Referencing uninitialized memory uninitref .48 5.36 Subtracting or comparing two pointers that do not refer to the same array ptrobj 49 5.37 Tainted strings are passed to a string copying function taintstrcpy .50 ISO/IEC TS 17961:2013(E)iv ISO/IEC 2013 All

    14、rights reserved 5.38 Taking the size of a pointer to determine the size of the pointed-to type sizeofptr 50 5.39 Using a tainted value as an argument to an unprototyped function pointer taintnoproto .51 5.40 Using a tainted value to write to an object using a formatted input or output function taint

    15、formatio .52 5.41 Using a value for fsetpos other than a value returned from fgetpos xfilepos .52 5.42 Using an object overwritten by getenv, localeconv, setlocale, and strerror libuse 53 5.43 Using character values that are indistinguishable from EOF chreof 54 5.44 Using identifiers that are reserv

    16、ed for the implementation resident 55 5.45 Using invalid format strings invfmtstr 57 5.46 Tainted, potentially mutilated, or out-of-domain integer values are used in a restricted sink taintsink .58 Annex A (informative) Intra- to Interprocedural Transformations 59 Annex B (informative) Undefined Beh

    17、a vior .63 Annex C (informative) Related Guidelines and References .71 Annex D (informative) Decidability of Rules .77 Bibliography .78 ISO/IEC TS 17961:2013(E) Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the speciali

    18、zed system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical commi

    19、ttees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Internationa

    20、l Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Pub

    21、lication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. In other circumstances, particularly when there is an urgent market requirement for such documents, the joint technical committee may decide to publish an ISO/IEC Technical Specification (

    22、ISO/IEC TS), which represents an agreement between the members of the joint technical committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting a vote. An ISO/IEC TS is reviewed after three years in order to decide whether it will be confirmed for a f

    23、urther three years, revised to become an International Standard, or withdrawn. If the ISO/IEC TS is confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an International Standard or be withdrawn. Attention is drawn to the possibility that some

    24、 of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO/IEC TS 17961 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 22, Programming languages, their e

    25、nvironments and system software interfaces. ISO/IEC 2013 All rights reserved v ISO/IEC TS 17961:2013(E) Introduction Background An essential element of secure coding in the C programming language is a set of well-documented and enforceable coding rules. The rules specified in this Technical Specific

    26、ation apply to analyzers, including static analysis tools and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis. The application of static analysis to security has been done in an

    27、 ad hoc manner by different vendors, resulting in nonuniform coverage of significant security issues. This specification enumerates secure coding rules and requires analysis engines to diagnose violations of these rules as a matter of conformance to this specification. These rules may be extended in

    28、 an implementation-dependent manner, which provides a minimum coverage guarantee to customers of any and all conforming static analysis implementations. The largest underserved market in security is ordinary, non-security-critical code. The security-critical nature of code depends on its purpose rat

    29、her than its environment. The UNIX finger daemon (fingerd ) is an example of ordinary code, even though it may be deployed in a hostile environment. A user runs the client program, finger, which sends a user name to fingerd over the network, which then sends a reply indicating whether the user is lo

    30、gged in and a few other pieces of information. The function of fingerd has nothing to do with security. However, in 1988, Robert Morris compromised fingerd by triggering a buffer overflow, allowing him to execute arbitrary code on the target machine. The Morris worm could have been prevented from us

    31、ing fingerd as an attack vector by preventing buffer overflows, regardless of whether fingerd contained other types of bugs. By contrast, the function of /bin/login is purely related to security. A bug of any kind in /bin/login has the potential to allow access where it was not intended. This is sec

    32、urity-critical code. Similarly, in safety-critical code, such as software that runs an X-ray machine, any bug at all could have serious consequences. In practice, then, security-critical and safety-critical code have the same requirements. There are already standards that address safety-critical cod

    33、e and therefore security-critical code. The problem is that because they must focus on preventing essentially all bugs, they are required to be so strict that most people outside the safety-critical community do not want to use them. This leaves ordinary code like fingerd unprotected. This Technical

    34、 Specification has two major subdivisions: preliminary elements (Clauses 14) and secure coding rules (Clause 5). Each secure coding rule in Clause 5 has a separate numbered subsection and a unique section identifier enclosed in brackets (for example, ptrcomp). The unique section identifiers are main

    35、ly for use by other documents in identifying the rules should the section numbers change because of the addition or elimination of a rule. These identifiers may be used in diagnostics issued by conforming analyzers, but analyzers are not required to do so. Annexes provide additional information. Ann

    36、ex C (informative) Related Guidelines and References identifies related guidelines and references per rule. A bibliography lists documents referred to during the preparation of this Technical Specification. The rules documented in this Technical Specification do not rely on source code annotations o

    37、r assumptions of programmer intent. However, a conforming implementation may take advantage of annotations to inform the analyzer. The rules, as specified, are reasonably simple, although complications can exist in identifying exceptions. An analyzer that conforms to this Technical Specification sho

    38、uld be able to analyze code without excessive false positives, even if the code was developed without the expectation that it would be analyzed. Many analyzers provide methods that eliminate the need to research each vi ISO/IEC 2013 All rights reserved ISO/IEC TS 17961:2013(E) diagnostic on every in

    39、vocation of the analyzer. The implementation of such a mechanism is encouraged but not required. This Technical Specification assumes that an analyzers visibility extends beyond the boundaries of the current function or translation unit being analyzed (see Annex A (informative) Intra- to Interproced

    40、ural Transformations). Completeness and soundness The rules specified in this Technical Specification are designed to provide a check against a set of programming flaws that are known from practical experience to have led to vulnerabilities. Although rule checking can be performed manually, with inc

    41、reasing program complexity, it rapidly becomes infeasible. For this reason, the use of static analysis tools is recommended. It should be recognized that, in general, determining conformance to coding rules is computationally undecidable. The precision of static analysis has practical limitations. F

    42、or example, the halting theorem of Computer Science states that there are programs whose exact control flow cannot be determined statically. Consequently, any property dependent on control flowsuch as haltingmay be indeterminate for some programs. A consequence of this undecidability is that it may

    43、be impossible for any tool to determine statically whether a given rule is satisfied in specific circumstances. The widespread presence of such code may also lead to unexpected results from an analysis tool. Annex D (informative) Decidability of Rules provides information on the decidability of rule

    44、s in this Technical Specification. However checking is performed, the analysis may generate false negatives: Failure to report a real flaw in the code is usually regarded as the most serious analysis error, as it may leave the user with a false sense of security. Most tools err on the side of cautio

    45、n and consequently generate false positives. However, there may be cases where it is deemed better to report some high-risk flaws and miss others than to overwhelm the user with false positives. false positives: The tool reports a flaw when one does not exist. False positives may occur because the c

    46、ode is sufficiently complex that the tool cannot perform a complete analysis. The use of features such as function pointers and libraries may make false positives more likely. To the greatest extent feasible, an analyzer should be both complete and sound with respect to enforceable rules. An analyze

    47、r is considered sound with respect to a specific rule if it cannot give a false-negative result, meaning it finds all violations of a rule within the entire program. An analyzer is considered complete if it cannot issue false-positive results, or false alarms. The possibilities for a given rule are

    48、outlined in Table 1. Table 1 Completeness and soundness False positives False negatives Y N N Sound with false positives Complete and sound Y Unsound with false positives Complete and unsound The degree to which conforming analyzers minimize false-positive diagnostics is a quality of implementation

    49、issue. In other words, quantitative thresholds for false positives and false negatives are outside the scope of this Technical Specification. Security focus The purpose of this Technical Specification is to specify analyzable secure coding rules that can be automatically enforced to detect security flaws in C-conforming applications. To be considered a security flaw, a software bug must be triggerable by the actions of a malicious user or attacker.


    注意事项

    本文(ISO IEC TS 17961-2013 Information technology - Programming languages their environments and system software interfaces - C secure coding rules《信息技术 程序设计语言 环境和系统.pdf)为本站会员(ideacase155)主动上传,麦多课文档分享仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文档分享(点击联系客服),我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1 

    收起
    展开