外文翻译
原文1
Verifying Policy-Based Web Services Security
SECURITY POLICIES FOR WEB SERVICES
1 Web Services and XML Rewriting Attacks
We consider systems of SOAP processors distributed across multiple machines. The primitive message pattern is asynchronous communication of a single SOAP message from one processor to another. A common derived message pattern is a request-response protocol between a client and a server. A single SOAP processor (e.g., a web server) may act both as a client and a server. For example, acting as a server, it may receive a request and then, acting as a client of another server, send a new request and use the subsequent response to construct its response to the original request.
Each SOAP message conforms to an XML schema for an envelope, comprising an optional header element for routing, security, and other metadata, plus a mandatory body element containing the message payload. For instance, here is a simple (unprotected) envelope.
<Envelope>
<Header>
<To>http://BobsPetShop.com/service.asmx</To>
<Action>http://petshop/premium</Action>
<MessageId>uuid: 5ba86b04...</MessageId>
</Header>
<Body>
<GetOrder><orderId>20</orderId></GetOrder>
</Body>
</Envelope>
We treat SOAP faults as ordinary SOAP responses. For the sake of read-ability, our presentation omits many details of the XML wire format, such as XML namespace information, and uses an abstract syntax for policies and configurations. Our formalism retains many details of the XML syntax, as they matter for security; for example, an XML signature may cover some chosen subset of the SOAP headers, so our model needs to represent the various headers. Even though our formalism hides some of the XML details, our tools directly consume and produce the XML file formats used by WSE.
There is a risk, of course, that SOAP messages may be read in transit by a passive attacker able to read network traffic. Moreover, SOAP messages may be created, modified, and replayed by an active attacker able to inject messages into the network. (In fact, the flexibility and explicitness of SOAP messages also make such attacks easier to set up.) The usual solution is to secure messages with cryptography. The details are subtle. The incorrect use of cryptography may leave vulnerabilities open to attack, as described by Needham and Schroeder [1978]. The conservative recommendation of Needhamand Schroeder is that the security goals of protocols based on cryptography should be established even in the presence of a demanding adversary: one who is in control of the network, has the use of some of the cryptographic keys belonging to principals of the system, and may employ these keys in attacks against other principals.
2 WS-Security
As we discuss elsewhere [Bhargavan et al. 2005a], WS-Security provides a precise grammar and default processing for elements in the security header, but prescribes no fixed protocol itself.Hence,compared to traditional transport security, WS-Security is more flexible, yet more costly in terms of performance and complexity.
In this article, we consider two representative sorts of security token; the standard defines several others. An X.509 token supports XML encryption and signature based on public-key cryptography. It is an XML element whose convent is an encoding of an X.509 certificate, a binary format including a subject name and a public key, jointly signed by a private key of some certification authority.
A username token [Nadalin et al. 2004a] supports XML signature based on password sharing. It is an XML element that always includes a username and may include other elements such as a timestamp and a nonce. Provided sender and receiver know the password associated with the username, they can derive a shared symmetric key from the token by hashing the password with the timestamp and nonce, and then use this key to produce and verify the MAC embedded in the signature. The mechanism for key derivation is left unspecified in the standard. For concreteness, we follow the WSE implementation, which uses the P SHA1 function defined in TLS [Dierks and Rescorla 2006] to derive keys that are used for message authentication—but not for encryption. However, this does not reflect a limitation in our formalism or analyses, which can be used to model both signature and encryption using a variety of key derivation algorithms.
We assume a population of known principals, principals able to authenticate their identity via passwords or public keys. For simplicity, principals are identified by their name, as it appears in security tokens: the subject field in X.509 certificates, and the username element in username tokens. We let names range over arbitrary strings. We say a security token is known if it is recognized by the system. An X.509 token is known if the underlying X.509 certificate is issued by an acceptable certification authority. A username token is known if the corresponding username and password are registered in the password database. Not all known principals are trusted to keep their cryptographic materials secret (see Section 3.4).
作者：Karthikeyan Bhargavan,Cédric Fournet,Andrew D. Gordon
国籍：英国
出处：Verifying policy-based security for web services
译文1
验证基于策略的Web服务安全性
Web服务的安全策略
1. Web服务和XML重写攻击
我们认为SOAP处理器系统分布在多台机器。原始消息模式是从发送端到接收端的单向异步传输。一个共同产生的信息模式是服务器120和客户端之间的一个请求响应协议。一个单一的SOAP处理器（例如， Web服务器）可能扮演客户端和服务器的双重角色。举例来说，作为服务器，它可能会收到一个请求；而作为另一台服务器的客户端，它发送新的请求并使用随后的响应去构建针对原来请求的响应。
每个SOAP消息符合一个封装的XML架构，包括一个为路由，安全和其他元数据提供可选的Header元素，再加上包含消息的有效载荷的强制性Body元素，举例来说，下面是 一个简单的（无保护）的封装。
<Envelope>
<Header>
<To>http://BobsPetShop.com/service.asmx</To>
<Action>http://petshop/premium</Action>
<MessageId>uuid:5ba86b04...</MessageId>
</Header>
<Body>
<GetOrder><orderId>20</orderId></GetOrder>
</Body>
</Envelope>
我们将SOAP故障作为普通的SOAP响应。为了读的方便，我们的介绍忽略了许多XML格式的细节，如XML命名空间信息，并使用一个抽象的语法策略和配置。我们的形式上要求保留许多XML语法的细节，如他们的安全问题；例如，一个XML签名可能包括一些子SOAP标头的选择，那么我们的模式需要代表不同标题。即使我们的形式伤舍弃了一些XML的细节，我们的直接使用WSE来制作所需要的XML文件格式。
当然，有一种危险存在：SOAP消息在传输过程中可能被攻击者截取。此外， SOAP消息可以被主动攻击者创建，修改和重放，攻击者能够将信息注入到网络。 （事实上，SOAP消息的灵活和清晰也使这种攻击更容易设置。）通常的解决办法是，加密以确保邮件安全传输。这个细节是比较精细的。不当的使用加密可能使漏洞置于公开袭击之下，就像Needham 和Schroeder [ 1978 ]所描述的那样。Needhamand Schroeder保守的建议是，基于安全目标的对协议应当建立加密，即使在出现的攻击者：一个可以控制网络，利用一些系统的关键密钥攻击其他代理的人。
2. web服务安全
就像我们其他地方讨论的一样， Web服务安全提供了一个精确的语法和元素的安全性标题默认处理方法，但没有规定固定的协议。因此，相比传统的安全传输，web服务安全更加灵活，但对性能和复杂度要求更高。
在本文中，我们考虑两个代表类型的安全令牌；该标准定义了几个元素。一个象征性的X.509支持XML加密和基于公共密钥加密签名。这是一个XML元素，它的内容是一个X.509证书的编码，其中二进制格式包括一个主题名称和一个公共密钥，还加入了一些验证的密钥。用户名令牌[ Nadalin，2004年]支持密码共享于XML基础上的签名。一个XML元素总是包含一个用户名，并且还可能包括其他因素，如时间戳和图片。假如发送方和接收方知道密码和用户名的关系，他们就可以从用户名令牌通过和时间戳以及图片相关的散列码得出一个共同的对称密钥，然后使用这个密钥产生和验证嵌入签名的MAC。密钥产生的标准机制尚不明确。或者，我们按照WSE的执行，使用的P _SHA1函数界定的TLS [ Dierks和Rescorla 2006 ]获取密钥用于邮件验证，但不进行加密。然而，这并没有反映在我们的形式体系或局限性分析上，即可用于模型签字也可使用各种密钥推导算法的加密。
我们假定已知的负责人，他们能够通过密码或公共密钥验证他们的身份。简单来说，负责人通过名字确定他们的身份，就像安全令牌所表现的一样：用户名令牌的主题领域中的X.509 证书的用户名和内容。我们名称允许范围内的任意字符串。就如我们所说的，安全令牌是已知的，那么它能够被系统识别出。如果另一个用户名令牌的X.509证书可以被系统识别出，那么它就是已知的。一个用户的用户名都有一个对应的数据库中已登记注册的密钥。当然不是所有的用户都能保护他们的密钥资料。（见第3.4节）
原文2
ASP.NET
ASP.NET is a web application framework developed and marketed by Microsoft to allow programmers to build dynamic web sites, web applications and web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET components to process SOAP messages.
History
After the release of Internet Information Services 4.0 in 1997, Microsoft began researching possibilities for a new web application model that would solve common complaints about ASP, especially with regard to separation of presentation and content and being able to write "clean" code.Mark Anders, a manager on the IIS team, and Scott Guthrie, who had joined Microsoft in 1997 after graduating from Duke University, were tasked with determining what that model would look like. The initial design was developed over the course of two months by Anders and Guthrie, and Guthrie coded the initial prototypes during the Christmas holidays in 1997.
The initial prototype was called "XSP"; Guthrie explained in a 2007 interview that, "People would always ask what the X stood for. At the time it really didn't stand for anything. XML started with that; XSLT started with that. Everything cool seemed to start with an X, so that's what we originally named it." The initial prototype of XSP was done using Java,but it was soon decided to build the new platform on top of the Common Language Runtime(CLR), as it offered an object-oriented programming environment,Garbage collection and other features that were seen as desirable features that Microsoft's Component Object Model platform didn't support. Guthrie described this decision as a "huge risk", as the success of their new web development platform would be tied to the success of the CLR, which, like XSP, was still in the early stages of development, so much so that the XSP team was the first team at Microsoft to target the CLR.
With the move to the Common Language Runtime, XSP was re-implemented in C#(known internally as "Project Cool" but kept secret from the public), and the name changed to ASP+, as by this point the new platform was seen as being the successor to Active Server Pages, and the intention was to provide an easy migration path for ASP developers.
Mark Anders first demonstrated ASP+ at the ASP Connections conference in Phoenix, Arizona on May 2, 2000. Demonstrations to the wide public and initial beta release of ASP+ (and the rest of the .NET Framework) came at the 2000 Professional Developers Conference on July 11, 2000 in Orlando, Florida. During Bill Gates' keynote presentation, Fujitsu demonstrated ASP+ being used in conjunction with COBOL, and support for a variety of other languages was announced, including Microsoft's new Visual Basic .Net and C# languages, as well as Python and Perl support by way of interoperability tools created by ActiveState.
Once the ".NET" branding was decided on in the second half of 2000, it was decided to rename ASP+ to ASP.NET. Mark Anders explained on an appearance on ''The MSDN Show'' that year that, "The .NET initiative is really about a number of factors, it's about delivering software as a service, it's about XML and web services and really enhancing the Internet in terms of what it can do ... we really wanted to bring its name more in line with the rest of the platform pieces that make up the .NET framework."
After four years of development, and a series of beta releases in 2000 and 2001, ASP.NET 1.0 was released on January 5, 2002 as part of version 1.0 of the .NET Framework. Even prior to the release, dozens of books had been written about ASP.NET, and Microsoft promoted it heavily as part of their platform for web services. Guthrie became the product unit manager for ASP.NET, and development continued apace, with version 1.1 being released on April 24, 2003 as a part of Windows Server 2003. This release focused on improving ASP.NET's support for mobile devices.
Pages
.NET pages, known officially as "web forms", are the main building block for application development. Web forms are contained in files with an ".aspx" extension; these files typically contain static (X)HTML markup, as well as markup defining server-side Web Controls and User Controls where the developers place all the required static and dynamic content for the web page. Additionally, dynamic code which runs on the server can be placed in a page within a block <% -- dynamic code -- %> which is similar to other web development technologies such as PHP, JSP, and ASP, but this practice is generally discouraged except for the purposes of data binding since it requires more calls when rendering the page.
Code-behind model
Microsoft recommends dealing with dynamic program code by using the code-behind model, which places this code in a separate file or in a specially designated script tag. Code-behind files typically have names like MyPage.aspx.cs or MyPage.aspx.vb while the page file is MyPage.aspx (same filename as the page file (ASPX), but with the final extension denoting the page language). This practice is automatic in Microsoft Visual Studio and other IDEs. When using this style of programming, the developer writes code to respond to different events, like the page being loaded, or a control being clicked, rather than a procedural walk through the document.
ASP.NET's code-behind model marks a departure from Classic ASP in that it encourages developers to build applications with separation of presentation and content in mind. In theory, this would allow a web designer, for example, to focus on the design markup with less potential for disturbing the programming code that drives it. This is similar to the separation of the controller from the view in model-view-controller frameworks.
User controls
An event bubbling mechanism provides the ability to pass an event fired by a user control up to its containing page.
Custom Controls
Programmers can also build Custom controls for ASP.NET applications. Unlike User controls, these controls don't have an ASCX markup-file, having all their code compiled into a DLL-file. Such Custom controls can be used across multiple web-applications and Visual Studio projects (which is not allowed with User controls). By using a Register directive, the control is loaded from the DLL.
Rendering technique
ASP.NET uses a visited composites rendering technique. During compilation, the template (.aspx) file is compiled into initialization code which builds a control tree (the composite) representing the original template. The initialization code is combined with user-written code (usually by the assembly of multiple partial classes) and results in a class specific for the page.
Actual requests for the page are processed through a number of steps. First, during the initialization steps, an instance of the page class is created and the initialization code is executed. This produces the initial control tree which is now typically manipulated by the methods of the page in the following steps. As each node in the tree is a control represented as an instance of a class, the code may change the tree structure as well as manipulate the properties/methods of the individual nodes. Finally, during the rendering step a visitor is used to visit every node in the tree, asking each node to render itself using the methods of the visitor. The resulting HTML output is sent to the client.
After the request has been processed, the instance of the page class is discarded and with it the entire control tree. This is usually a source of confusion among novice ASP.NET programmers that rely on class instance members that are lost with every page request/response cycle.
State management
ASP.NET applications are hosted by a web server and are accessed using the stateless HTTP protocol. As such, if an application uses stateful interaction, it has to implement state management on its own. ASP.NET provides various functions for state management. Conceptually, Microsoft treats "state" as GUI state; problems may arise if an application needs to keep track of "data state", for example, a finite state machine which may be in a transient state between requests (lazy evaluation) or which takes a long time to initialize.
Application state
Application state is held by a collection of shared user-defined variables. These are set and initialized when the Application_OnStart event fires on the loading of the first instance of the applications and are available till the last instance exits. Application state variables are accessed using the Applications collection, which provides a wrapper for the application state variables. Application state variables are identified by name.
Session state
Server-side session state is held by a collection of user-defined session variables, which are persisted during a user session. These variables, accessed using the Session collection, are unique to each session instance. Then variables can be set to be automatically destroyed after a defined time of inactivity, even if the session does not end. Client-side user session is maintained by either a cookie or by encoding the session ID in the URL itself.
作者：Stephen Walther
国籍：美国
出处：http://www.informit.com/articles/article.aspx?p=25467
译文2
ASP.NET
ASP.NET是由MicroSoft公司开发出的Web应用程序框架，程序员能够建立动态网站，网络应用和Web服务。2002年1月，首次发布了1.0版本的.NET框架，是微软的Active Server Pages（ASP）技术的继任者。ASP.NET是建立在公共语言运行库（CLR）上，允许程序员使用任何受支持的.NET语言来编写代码。ASP.NET SOAP扩展框架允许ASP.NET组件来处理SOAP消息。
历史
1997年IIS4.0版本发布后，为了解决关于ASP常见的问题，尤其是编排和代码分离，微软开始研究一个新的网络应用模式。IIS开发队的经理Mark Anders和1997年毕业于Duke University的Scott Guthrie，微软决定让他们考虑模型。Anders和Guthrie用了2个多月完成了最初的设计，1997年圣诞节期间，Guthrie编写了原型。
最初的原型被称为“XSP”，Guthrie在2007年采访时解释说，“人们总是问X代表什么，但在那时X并不代表什么。XML、XSTL都是以X开头，好像每样都以X开头，因此我们也就那样命名了。” XSP的初始原型是用Java完成的，但它很快就决定建立公共语言运行库（CLR）的新平台，因为它提供了一个面向对象的编程环境，垃圾处理和其他功能，被视为理想的平台，微软的组件对象模型不支持的平台。Guthrie形容这是一个“巨大危险”的决定，新的Web开发平台的成功依赖于CLR的，像XSP，仍处于发展的初期阶段，以至于XSP的开发团队成为微软第一支面向CLR的团队。
随着向公共语言运行时移动，XSP重新用C＃（内部称为“项目酷”，但对外一直保密）实现，改称ASP+，在这点上，被视为Active Server Pages的下一个版本，为ASP开发人员提供了一个轻松升级路径。
2000年5月2日，在Arizona 的Phoenix的ASP大会上，Mark Anders首次展示了ASP+。2000年7月11日，在Orlando的Florida的专业开发者大会上，向大众解释并初步测试了ASP +（以及其他的.NET框架）。在Bill Gates的主题演讲会上，Fujitsu展示了正在使用COBOL的 ASP + ，宣称支持多种语言，包括微软的Visual Basic、.NET和C＃语言，以及Python和Perl支持的由ActiveState方式建立互操作性的工具。
2000年下半年决定“.NET”品牌，把ASP +改称ASP.NET。Mark Anders针对这一年的“MSDN显示”的外观解释说：“.NET最初影响的因素很多,给客户提供软件服务，关于XML和Web服务，切实加强了互联网的某些方面……我们真的想把其他平台拼一块组成.NET框架。”
经过4年的发展，并于2000年和2001年的一系列测试中，2002年1月5日发布的ASP.NET 1.0版本作为.NET框架的一部分，并晋升为微软的Web服务平台。Guthrie成为ASP.NET的产品部经理，.NET发展的很迅速，在2003年4月24日开发了1.1版本的，作为Windows Server 2003的一部分。集中提高ASP.NET对移动设备的支持。
页面
.NET页面，被称为“Web窗体”，是应用开发的主要组成部分。Web窗体包含以后缀名为“.aspx”的文件，这些文件通常包含静态（X）HTML的标记，也标记定义的服务器端Web控件和用户控件，开发者根据Web页面的动静态内容需求进行定位。此外，在服务器上运行的动态代码，可放置在一个页面内块<％ - 动态代码 - ％>，这类似于其他Web开发技术，如PHP，JSP和ASP的，但除了呈现页面需要更多的需求时数据绑定外，这种做法是普遍的。
代码隐藏类
Microsoft建议使用代码隐藏模型处理动态程序代码，将它放在一个单独的文件中或一个专门指定的脚本标记。当页面文件为MyPage.aspx，代码隐藏文件通常命名为MyPage.aspx.cs或MyPage.aspx.vb。Microsoft Visual Studio和其他IDE自动使用这种做法。当使用这种编程风格时，开发人员编写代码以响应不同的事件，就像页面被加载，或控件被点击，而不是通过文件。
ASP.NET的代码隐藏模型标志着它从传统的ASP中分离出来，鼓励开发者创建表现形式和内容分离的应用程序。从理论上讲，举个例子来说，这将允许网页设计师集中在设计上，把重点放在较少的程序代码扰乱驱动它潜在的设计标记。这是类似于模型视图控制器框架视图控制器分离。
用户控件
事件冒泡机制提供了能够通过由一个用户控件激发事件至其包含页。
自定义控件
程序员也可以建立ASP.NET应用程序自定义控件。不像用户控件，这些控件没有ASCX标记文件，所有的代码都编译到一个DLL文件。这种自定义控件可以用作多个Web应用程序和Visual Studio项目（不允许使用用户控件）。通过使用Register指令，可以从dll中加载控件。
渲染技术
ASP.NET使用一个访问了复合材料的渲染技术。在编译过程中，模板（.aspx）文件被编译成初始化代码，生成一个控件树（综合）代表原始模板。初始化代码是结合用户编写的代码（通常情况下由多个部分类聚合），作用于一类特定的页面。
网页的实际请求是通过一系列步骤进行处理的。首先，在初始化阶段，一个页面类的实例被创建，初始化代码被执行。这产生了初步控制树，现在通常由页面的方法通过以下步骤操纵。由于树中的每个节点被认为是一个类的实例代表，代码可能改变树的结构以及操控单个节点的属性和方法。最后，在渲染阶段，访问者习惯于访问树中的每个节点，请求每个节点使用游客的方法渲染自己。由此产生的HTML输出并发送到客户端。
该请求被处理后，此页面类的实例将被丢弃，并用它来控制整棵树。ASP.NET初学者依赖于类的实例成员，以至每一个页面请求/响应周期丢失，成了混乱的来源。
状态管理
ASP.NET应用程序是由Web服务器托管，并使用无状态的HTTP协议进行访问。因此，如果一个应用程序使用有状态的交互，它必须执行自己的状态管理。ASP.NET为状态管理提供了各种功能。从概念上讲，Microsoft将“状态”看作图形用户界面(GUI)的状态；如果应用程序需要保持“数据状态”的路径可能会产生一些问题，例如，有限状态机可在请求之间（懒惰评估）或需占很长一段时间来初始化。
全局状态
全局状态集合了用户定义的变量，加载第一个实例的应用程序时Application_OnStart事件触发，变量开始初始化，直到最后一个实例用完才释放。全局状态变量通过应用程序集进行访问，它为全局状态变量提供了一个包装。全局状态变量名称是确定的。
局部状态
服务器端的会话状态举行一个用户定义的会话变量集合，它是在一个用户会话仍然存在。这些变量，访问使用会话集合，是唯一的每个会话实例。然后变量可以被设定为自动销毁不活动后规定的时间，即使会议没有结束。客户端用户会议是由任何一个cookie或URL中编码本身的会话ID。
