WebGoat--Authentication Flaws-Basic Authentication 感想

课程概念的的确确讲了关于基本认证的过程。客户端一开始请求资料，服务端为了保护资源，发给客户端一个401认证，用户输入账号和密码之后客户端用base64加密传回服务端。服务端对其进行验证，如果正确，则返回资源。在这之后，验证消息在每次连接都会自动带上。

好了，差不多说的就是这点事。最重要的没说....我是做到第二步卡死了。很天真的认为改Authorization头里面的Basic就可以了。

但是，告诉我接近了，但是不对，让我自己在好好想一想。行，我就把cookie删掉了。试，结果返回开始页面了。但是Authorization字段没有变。很是无语。当时还年轻啊，执着的改认证头，就是不变，cookie都变了，认证头为什么不变。不懂背后一系列的机制，吃的苦不小啊。试到后面生气了，就果断删除了cookie和Authorization。哈哈，这下我直接用basic登陆总行吧。很开心的输入的用户名和密码。确认一回来。。。天，还是老样子。恩，想到办法了，换个浏览器，用basic登陆呗。呵呵，貌似那个上面通过了。

经过一番不懂方法技巧，对于背后机制毫不了解的尝试之后。看解决方案吧。。。。照着做了一遍。通过了。

要是今天不在弱认证码上面卡了大半天也不会想到这个，因为自己觉得看懂生成WEAK-ID的方法，就是ID+'-'+时间。所以就用赶紧临时补充一下python里面http库的函数用法，写了一个暴利测试认证码的程序。结果，呵呵，没出来。我回去自己一试，的确出不来，试玩之后又改回去了。要是把字段删了，就直接给你再分配一个。删了session就重新来了。于是我想到关于这个该死的cookie好像以前弄过。就把那个课程拿出来研究研究。这下自我感觉弄通了。道理很简单啊，其实就是客户端一直保存着cookie和Authorization。只要有正确的验证头，服务器就不会让你再认证了。于是客户端，也就是浏览器一直发缓存里面的认证头。恩，首先要搞定本地的认证头，就是让服务器重新验证你。人家凭什么验证你呢?就是你发过去没有验证头（或者有错误）。然后不要忘记了，你在服务器这边搞定了，但是浏览器这里还记得你的会话连接（cookie)，为了让它也与时俱进，我们就要让服务端在给它分配一个新的cookie。弄个不对的就行了。到这里，就差不多了。

最后抱怨一句，干什么外行都容易被欺负，我相信懂这方面机制的话，这种课程特别容易解决。