计算机网络作业
第13题 (2.0) 分
当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条（ ） 。
没给答案？
是不是写错了，如果是tcp，答案应该是虚电路。
第20题 (2.0) 分
WWW上的每个网页都有一个独立的地址，这些地址统称为( c ).
A、域名
B、IP地址
C、URL
D、MAC地址
解析：UR统一资源定位符（URL，英语 Uniform / Universal Resource Locator 的缩写）也被称为网页地址，是因特网上标准的资源的地址（Address)。Internet上的每一个网页都具有一个唯一的名称标识，通常称之为URL地址，这种地址可以是本地磁盘，也可以是局域网上的某一台计算机，更多的是Internet上的站点。简单地说，URL就是Web地址，俗称“网址”。
填空题
第31题 (3.0) 分
提高信息的传输速率最有效的办法是使用___多路复用______ 的方法。
第32题 (2.0) 分
控制两个对等实体进行通信时约定的规则的集合称为__协议______。
第33题 (2.0) 分 因为IP地址既对一个网络编码，也对那个网络上的一台主机编码，所以，它们不是确定单个主机，而是确定__________。
第34题 (2.0) 分 互联网分组转发通常包括三种情况____________、____________和____________。
第35题 (2.0) 分
差错是不可避免的，传输错误的比特占所传输比特总数的比率称(误码率)
第36题 (2.0) 分
如果数据传输过程不出差错，接收方收到一个正确的数据帧后，向发送方发送一个确认帧ACK，当发送方收到ACK后才能发送一个新的数据帧，这是__tcp/ip_____协议的工作原理
第37题 (2.0) 分 通常有两种不同的加密策略，即___链路加密___与___端到端加密
第38题 (2.0) 分 因特网的拓扑结构复杂，且覆盖全球，但从工作方式上看，可以划分为边缘部分和____核心___部分。
第39题 (2.0) 分 时延是指一个报文或分组从一个网络（或一条链路）的一端传送到另一端所需的时间。
第40题 (3.0) 分 同一系统中相邻两层的实体进行信息交互的地方称为_服务访问点，它实际上就是一个逻辑接口。
问答题
第41题 (5.0) 分
分别自举一个A类IP地址和一个C类IP地址，并分别写出默认情况下其对应的子网掩码。
答：A类IP地址：范围从 1.0.0.1 到 126.255.255.254 的单址广播 IP 地址。第一个八位字节指明网络，后三个八位字节指明网络上的主机。子网掩码：255.0.0.0
C类IP地址:范围从 192.0.0.1 到 223.255.255.254 的单址广播 IP 地址。前三个八位字节指明网络，后一个八位字节指明网络上的主机。子网掩码：255.255.255.0
第42题 (11.0) 分
简述载波侦听多路访问/冲突检测法CSMA/CD的要点
答：CSMA/CD是一种分布式介质访问控制协议，网中的各个站（节点）都能独立地决定数据帧的发送与接收。每个站在发送数据帧之前，首先要进行载波监听，只有介质空闲时，才允许发送帧。这时，如果两个以上的站同时监听到介质空闲并发送帧，则会产生冲突现象，这使发送的帧都成为无效帧，发送随即宣告失败。每个站必须有能力随时检测冲突是否发生，一旦发生冲突，则应停止发送，以免介质带宽因传送无效帧而被白白浪费，然后随机延时一段时间后，再重新争用介质，重发送帧。CSMA/CD协议简单、可靠，其网络系统（如Ethernet）被广泛使用。
第44题 (7.0) 分
链路与数据链路有什么区别？
答：链路(物理链路)的任务是将用二进制表示的信息转变为可在实际线路上传输的物理状态。
数据链路的任务是在二进制的基础上识别报文的机制。这个任务是通过对等的数据链路层间传送报文来完成的。根据不同的应用要求，该层数据报文所传的数据可以是一串字符，也可以是一串二进制位，当然，因为字符在信息传输中也用它的编码即一个二进制位进行传
输，所以前者是后者的特例
判断题以后再给你补吧……
试解释 SQL 注入攻击的原理，以及对数据库可能产生的不利影响。
SQL注入就是攻击者通过正常的WEB页面,把自己SQL代码传入到应用程序中,从而通过执行非程序员预期的SQL代码,达到窃取数据或破坏的目的。
当应用程序使用输入内容来构造动态SQL语句以访问数据库时，会发生SQL注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生SQL注入。SQL注入可能导致攻击者使用应用程序登陆在数据库中执行命令。如果应用程序使用特权过高的帐户连接到数据库，这种问题会变得很严重。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或者作为存储过程的输入参数，这些表单特别容易受到SQL注入的攻击。而许多网站程序在编写时，没有对用户输入的合法性进行判断或者程序中本身的变量处理不当，使应用程序存在安全隐患。这样，用户就可以提交一段数据库查询的代码，根据程序返回的结果，获得一些敏感的信息或者控制整个服务器，于是SQL注入就发生了。
一般SQL注入
在Web 应用程序的登录验证程序中,一般有用户名(username) 和密码(password) 两个参数,程序会通过用户所提交输入的用户名和密码来执行授权操作。我们有很多人喜欢将SQL语句拼接起来。例如：
Select * from users where username =’ txtusername.Text ’ and password =’ txtpassword.Text ’
其原理是通过查找users 表中的用户名(username) 和密码(password) 的结果来进行授权访问, 在txtusername.Text为mysql，txtpassword.Text为mary，那么SQL查询语句就为：
Select * from users where username =’ mysql ’ and password =’ mary ’
如果分别给txtusername.Text 和txtpassword.Text赋值’ or ‘1’ = ‘1’ --和abc。那么,SQL 脚本解释器中的上述语句就会变为:
Select * from users where username =’’or ‘1’ = ‘1’ -- and password =’abc’
该语句中进行了两个条件判断,只要一个条件成立,就会执行成功。而'1'='1'在逻辑判断上是恒成立的,后面的"--" 表示注释,即后面所有的语句为注释语句这样我们就成功登录。即SQL注入成功.
如果我们给txtusername.Text赋值为:’;drop table users--即:
Select * from users where username =’’;drop table users-- and password =’abc’
整个用户表就没有了，当然这里要猜出数据表名称。想想是多么可怕的事情。
好我想大家在这里已经大致明白了一般SQL注入了，试想下您的登录程序会不会出现我上述的情况。
防范SQL注入
那么现在大家都在思考怎么防范SQL注入了这里给出一点个人的建议
1.限制错误信息的输出
这个方法不能阻止SQL注入，但是会加大SQL注入的难度，不会让注入者轻易得到一些信息，让他们任意破坏数据库。SQL Server有一些系统变量，如果我们没有限制错误信息的输出，那么注入着可以直接从出错信息获取，例如（假定这里用的string即字符类型并可以发生SQL注入）：www.xxx/showdetail.aspx?id=49 and user>0 这句语句很简单，但却包含了SQL Server特有注入方法的精髓，。首先看看它的含义：首先，前面的语句是正常的，重点在and user>0，我们知道，user是SQL Server的一个内置变量，它的值是当前连接的用户名，类型为nvarchar。拿一个nvarchar的值跟int的数0比较，系统会先试图将nvarchar的值转成int型，当然，转的过程中肯定会出错，SQL Server的出错提示是：将nvarchar值 ”abc” 转换数据类型为 int 的列时发生语法错误，呵呵，abc正是变量user的值，这样，注入着就拿到了数据库的用户名。
众所周知，SQL Server的用户sa是个等同Adminstrators权限的角色，拿到了sa权限，几乎肯定可以拿到主机的Administrator了。上面的方法可以很方便的测试出是否是用sa登录，要注意的是：如果是sa登录，提示是将”dbo”转换成int的列发生错误，而不是”sa”。
当然注入者还可以输入不同的信息来得到他们想要的信息 ，上面只是其中一个例子，所以我们要限制错误信息的输出，从而保护我们的数据库数据，这里我给出.NET限制错误信息的方法：
在Web.Config文件中设置
<customErrors mode="On" defaultRedirect="error.aspx">
</customErrors>
这样当发生错误时候就不会讲信息泄露给外人。
2.限制访问数据库帐号的权限
对于数据库的任何操作都是以某种特定身份和相应权限来完成的,SQL语句执行前,在数据库服务器端都有一个用户权限验证的过程,只有具备相应权限的帐号才可能执行相应权限内的SQL语句。因此,限制数据库帐号权限,实际上就阻断了某些SQL语句执行的可能。不过,这种方法并不能根本解决SQL注入问题,因为连接数据库的帐号几乎总是比其他单个用户帐号拥有更多的权限。通过限制贴帐号权限,可以防止删除表的攻击,但不能阻止攻击者偷看别人的信息。
3.参数化使用命令
参数化命令是在SQL文本中使用占位符的命令。占位符表示需要动态替换的数据,它们通过Command对象Parameters集合来传送。能导致攻击的SQL代码可以写成:
Select * from employee where userID=@userID;
如果用户输入: 09105022’OR ‘1’=’1,将得不到何记录,因为没有一个用户ID与文本框中输入的’ 09105022’OR ‘1’=’1’相等。参数化命令的语法随提供程序的不同略有差异。对于SQL SERVER提供程序,参数化命令使用命名的占位符(具有唯一的名字),而对于OLE DB提供程序,每个硬编码的值被问号代替。使用OLE DB提供程序时,需要保证参数的顺序和它们出现在SQL字符串中的位置一致。SQL SERVER提供程序没有这样的需求,因为它们用名字和占位符匹配。
4.调用存储过程
存储过程是存储在数据库服务器上的一系列SQL代码,存储过程与函数相似,有良好的逻辑封装结构,可以接收和返回数据。使用存储过程可以使代码更易于维护,因为对存储过程的更改不会导致应用程序的重新编译,使用存储过程还可以节省带宽,提高应用程序性能。因为存储过程是存储在数据库服务端的独立的封装体,调用存储过程可以保证应用程序只执行存储过程中的固定代码,从而杜绝SQL语句注入的可能。结合上述所讲的参数化命令,可以实现SQL代码可以实现的任何功能,并进一步提高应用程序的安全等级。
5.限制输入长度
如果在Web页面上使用文本框收集用户输入的数据,使用文本框的MaxLength属性来限制用户输入过长的字符也是一个很好的方法,因为用户的输入不够长,也就减少了贴入大量脚本的可能性。程序员可以针对需要收集的数据类型作出一个相应的限制策略。
6.URL重写技术
我们利用URL重写技术过滤一些SQL注入字符，从而达到防御SQL注入。因为许多SQL注入是从URL输入发生的。
7.传递参数尽量不是字符
假设我们显示一篇新闻的页面，从URL传递参数中获得newid我们可能会随手写下下面的代码：
string newsid = Request.QueryString["newsid"];
string newssql = "select * from news where newsid=" + newsid;
如果传递过来的参数是数字字符就没有问题。但是如果传递过来的newsid是“1 delete from table ”的话，那么sql的值就变成了“select * from table where newsid=1 delete from news”。发生注入成功。但是这里改为
int newsid=int.Parse(Request.QueryString["newsid"].ToString());
string newssql = "select * from news where newsid=" + newsid.Tostring();
这里如果还是上面"1 delete from table "会发生错误，因为在转换时候出现了错误
从上面的一个小例子，我们得出在传递参数时候尽量不要用字符，免得被注入。
最后是我想扩展下利用URL重写技术来过滤一些SQL注入字符，首先这里有一篇关于URL重写的文章，我的基本思想是可以利用它，屏蔽一些危险的SQL注入字符串，这些字符串我们可以人为的设定，毕竟我们还是根据特定的环境设定我们防御措施。首先我们在ModuleRewriter类中的Rewrite函数得到绝对的URL判断其中是否有危险字符，如果有我们就将它链接到一个提示用户您输入危险的URL地址。如果不是我们继续判断是否触发了其他的URL重写的规则，触发了就重写。这样就大致上能在URL上防御危险字符。
代码
<configSections>
<section name="RewriterConfig" type="URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter" />
</configSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default_sql_error.aspx</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default2.aspx</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
<httpModules>
<add type="URLRewriter.ModuleRewriter, URLRewriter" name="ModuleRewriter" />
</httpModules>
上面是要在web.config配置文件加上的内容，这里我加上了两个重写规则，第一个规则是专门针对满足这个正则表达式的页面URL查看是否有危险字符，有危险字符就会发送到Default_sql_error.aspx页面，来示警。这里我假定会发生危险字符注入的页面时以"d"字符开头并加上数字的页面（这里我们可以根据实际情况自己定义，看哪些页面URL容易发生我们就制定这些页面的正则表达式），第二个是一般URL重写。因为这里我采用的是HTTP模块执行URL重写，所以加上<httpModules></httpModules>这一块。
第二步就是要在重写Rewrite函数了
代码
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// 获得配置规则
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;
//获得绝对的URL
Uri url = app.Request.Url;
// 判断url 中是否含有SQL 注入攻击敏感的字符或字符串,如果存在,sqlatFlag = 1 ;
string urlstr = url.AbsoluteUri;
int sqlatFlag = 0;
//这里我们根据实际情况随便编写，我这里这是随便列举了几个
string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";
string[] split = words.Split(',');
foreach (string s in split)
{
if (urlstr.IndexOf(s.ToUpper()) > 0)
{
sqlatFlag = 1;
break;
}
}
if (sqlatFlag == 1)
{
// 创建regex
Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
// 找到匹配的规则,进行必要的替换
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
// 重写URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
}
else
{
// 遍历除rules[0 ]以外的其他URL 重写规则
for (int i = 1; i < rules.Count; i++)
{
// 获得要查找的模式,并且解析URL (转换为相应的目录)
string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// 创建regex
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的规则
if (re.IsMatch(requestedPath))
{
// 找到了匹配的规则, 进行必要的替换
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// 重写URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;
// 退出For 循环
}
}
}
}
那么下一步就是检验例子了
首先我们输入localhost:4563/web/Default.aspx?id=1;--
这样localhost:4563/web/Default.aspx?id=1;-- 没有改变，就会显示Default_sql_error.aspx里内容“您输入了危险字符”。
再输入localhost:4563/web/D11.aspx就会显示 Default2.aspx内容，因为这里触发了第二个重写规则
防注入式攻击怎么回事？怎么做的？
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：
⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：
System.Text.StringBuilder query = new System.Text.StringBuilder（"SELECT * from Users WHERE login = '"）。Append（txtLogin.Text）。Append（"' AND password='"）。Append（txtPassword.Text）。Append（"'"）；
⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'.
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
二、如何防范？
好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' —— AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入
的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理