TONT 35713 当人们要将安全漏洞作为功能的时候:窃取密码

原文链接:https://devblogs.microsoft.com/oldnewthing/20050504-52/?p=35713

Sometimes people ask for features that are such blatant security holes I don’t know what they were thinking.

有些时候,有些人提出的功能需求完全就是安全漏洞,真不知道这些人脑子里都在想什么。

Is there a way to get the current user’s password? I have a program that does some stuff, then reboots the system, and I want to have the current user’s password so I can log that user back in when I’m done, then my program can resume its operation.

有没有办法获取当前用户的密码呢?我的程序会进行一些操作,然后重新启动系统,这时候我希望能获得用户的密码,这样重启完成后就能替用户进行登录,然后我的程序就能继续执行剩下的操作了。

(Sometimes they don’t bother explaining why they need the user’s password; they just ask for it.)

(有时候这些人连为什么需要用户的密码都懒得解释,就只是要而已。)

Imagine the fantastic security hole if this were possible. Anybody could write a program that steals your password without even having to trick you into typing it. They would just call the imaginary GetPasswordOfCurrentUser function and bingo! they have your password.

想象一下如果这件事成为可能的话,会产生一个多么美妙的安全漏洞。任何人都可以写一段程序来窃取你的密码,甚至不需要欺骗你把密码输进去,只需要调用那个虚构的 GetPasswordOfCurrentUser 方法就好了,一转眼,他们就拥有了你的密码。

For another angle on credential-stealing, read Larry Osterman‘s discussion of why delegation doesn’t work over the network.

或者也可以换个角度来观察凭据窃取这个问题,可以读一读  Larry Osterman 关于为什么代理认证在(内部)网络上行不通的文章。

Even if you didn’t want the password itself but merely some sort of “cookie” that could be used to log the user on later, you still have a security hole. Let’s call this imaginary function GetPasswordCookieOfCurrentUser; it returns a “cookie” that can be used to log the user on instead of using their password.

即便你不是想要密码本身,只是想要个某种形式的『Cookie』用于稍后替用户登录,这样操作同样也是一个安全漏洞。姑且将这个想象中的方法叫做 GetPasswordCookieOfCurrentUser,调用之会返回一个『Cookie』可以在稍后用于替用户登录,而不是直接返回用户的密码。

This is just a thinly-disguised GetPasswordOfCurrentUser because that “cookie” is equivalent to a password. Log on with the cookie and you are now that person.

这不过是前述的 GetPasswordOfCurrentUser 稍稍改头换面了一下而已,因为这个『Cookie』等同于密码,用这个『Cookie』登录之后你就是用户本人了。

(译注:Windows 10 看上去已经有了这篇15年前的文章描述的功能了——设置—账户—登录选项—『更新或重启后,使用我的登录信息自动完成设备设置并重新打开我的应用』,但仅限于系统更新或由系统发起的设备配置,而不是像这篇文章说的那样可以由第三方程序使用,且如果本机加入了域或应用了组策略,则该功能不可用。点击这里查看官方说明。)

Day 11531 关于『饭碗儿』的一些说明

由于饭否的页面及API设计,有关『饭碗儿』账号的一些说明写在个人简介中相当局促,在账号开设近5年后的今天,终于还是决定单列一个页面,对一些问题进行说明。

 

一、『饭碗儿』是什么

『饭碗儿』是一个对饭否『随便看看』栏目的统计账号。由于『随便看看』包含来自全站公开消息中的随机的20条左右的数据,在一定程度上可以作为饭否站内消息概况的一个缩影。

很多对『饭碗儿』的疑问都来源于对上述概念的不完整理解,如果您对『饭碗儿』的数据有疑问,请继续往下看。

 

二、『饭碗儿』的数据生成过程

『饭碗儿』的统计数据来源于对『随便看看』的数据采集。每个整秒分钟(如:8:00:00,或:13:45:00),『饭碗儿』的后台服务都会对『随便看看』进行一次数据采集,并将全量数据保存在本地备用。

每周一(理论上),『饭碗儿』的管理者(我)会用事先写好的工具将上周七天的数据进行统计,包含如下两类数据:

(一)客户端使用情况:在数据中查找名称『完全不同』的API名称(即『通过____发送』的中间部分,如:网页、御饭 iPhone 等等)进行计数统计。

(二)公共TL话痨50强:在数据中查找发送人、消息内容、发送时间完全不同的饭否消息,统计其所属的发送人出现的次数。

关于第(一)条,一个普通用户不容易注意到的细节是,API 返回中的 API 名称,除饭否官方 API 外(如『网页』,即饭否的PC端网页),原则上所有API都必填一个应用说明页面的URL,采集时,这类API名称会体现为:<a href=”http(s)://应用说明页面网址/”>API名称</a>。对于去掉<a>标签后名称相同的API,统计时会按照两条数据对待。

统计好之后,管理者还会对按要求提交排除申请用户和API名称进行处理,将这些数据进行剔除,最后制成图表,发送到账号上。

 

三、关于『饭碗儿』的一些疑问

倘若仔细读过了前述说明,仍未能解答您的疑问的话,这里有一些饭否用户对『饭碗儿』的一些问题,可供参考。

如您仍有其它下列未列出的问题,可在本文下方留言提问,确实未予回答的,本人会进行回复。

(〇)星期一了,怎么没发统计数据?

答:平日工作较忙,如未能准时发布,后面会尽量补上,请理解。未制作自动制图流程,因为我懒。

(一)随便统计别人发过的消息次数,你是不是变态?

答:『随便看看』中的消息,均由饭否官方通过自动的形式公开向登录用户进行展示,『饭碗儿』无法控制饭否『随便看看』功能展示的信息,仅对这些公开数据进行采集,且仅作为统计原始数据使用,没有将这些消息的内容进行转载、修改或任何妨害消息原发布者隐私权的行为,如果您认为『饭碗儿』的行为侵犯了您的个人权益,请参考下述第(二)条的方式,向『饭碗儿』主动提交从统计数据中移除的请求,否则视为同意『饭碗儿』对您出现在『随便看看』中消息的采集行为,『饭碗儿』不对任何人的玻璃心行为负责。如您仍有疑问,请恰饭否官方或法律人士进行咨询,『饭碗儿』保留对不合理的请求进行无视、在『饭碗儿』账号上进行公开发布的权利。

(二)因为个人原因,我不想让我的账号或API名称出现在『饭碗儿』的统计数据中,应该怎么做?

答:请通过饭否的『私信』功能,向『饭碗儿』发送私信,说明您(或您的API名称,此处建议您提供带有对应API名称的示例公开消息,以便准确定位)不想在『饭碗儿』的统计数据中出现即可,无需提供理由,除此之外的方式均视为无效,不予受理。『饭碗儿』将从消息收到之日起(视乎『饭碗儿』所有人登录饭否网查看私信之时间为准,不以消息发出时间为准)永久性地将您或您的API名称从『饭碗儿』的后续统计数据中移除。此外,由于饭否的功能限制,已发送的消息无法进行修改,故若已发送的统计数据中包含您或您提供的API名称,则无法进行移除,望知悉。

(三)为什么我说了那么多的话(为什么我的应用明明那么多人用),却没有上『饭碗儿』的『公共TL话痨50强』(客户端使用情况)的榜单?

答:请注意『饭碗儿』只是对『随便看看』数据的统计,由于饭否的『随便看看』是对全站公开数据的随机抽取,以上两种状况发生的原因有:(1)在每分钟采集时,『随便看看』中没有抽到您(的API)的消息;(2)统计期间您打开了隐私保护(即所谓的『上锁』),使得您的消息不会出现在『随便看看』中。

(四)为什么我(的API)在统计期间明明发了10000条消息,却只给我算了1000条?『饭碗儿』是不是把我拉黑了?

答:请注意『饭碗儿』只是对『随便看看』数据的统计,由于饭否的『随便看看』是对全站公开数据的随机抽取,数据存在一定的随机性,且『饭碗儿』并非针对单个用户(或API)个体进行数据统计,故只能代表您(的API)在『随便看看』中每整分钟采集时的情况,仅供参考,不能代表精确的情况。此外,『饭碗儿』从未也不会主动拉黑任何人或任何API名称,除非用户或API名称的持有人通过上述第(二)条中描述的方式提起请求,此时『饭碗儿』会按要求对相应的数据条目进行移除。

(五)为什么我(的API)发了10000条消息,然后又全删掉了,统计的时候还是给我算了8000条消息?

答:请注意『饭碗儿』只是对『随便看看』数据的统计,数据来自每个整分钟对『随便看看』进行采集,但不会后期再次验证拉取消息的删除情况,故拉取数据时已发送的消息均会列入统计。

(六)我有几个API名称,能不能帮我合成一条统计记录?

答:维护API名称是开发者的责任,不提供此服务。

(七)为什么客户端列表中有两个『网页』?

答:数量较多者为饭否官方的“网页版”,较少者为某系列机器人的API名称。

 

四、一点点『饭碗儿』的历史

『饭碗儿』账号建立于2015年10月12日,起初是因对饭否全站的消息词频等数据感兴趣而设立的。

最开始时,『饭碗儿』曾对客户端统计情况、公共TL话痨50强、消息时段分布及词频进行统计。后来经过一段时间的运行,消息时段分布因每次都几乎没有差别,没有太大意义而取消掉了,词频云则由于未能找到物美价廉的分词API而作罢,而余下的两种类型,则一直运行到今天。

『饭碗儿』运行至今,除了一大堆娱乐性图表外,还积累了另一份数据:2015年11月至今的饭否『随便看看』每周1.08万次的采集。尽管该数据因硬件故障、API故障、被意外封停等问题并非全量,但在某种意义上也是见证了饭否多年来公开的欢声笑语。

TONT 35853 当人们要将安全漏洞作为功能的时候:在资源管理器中隐藏文件

原文链接:https://devblogs.microsoft.com/oldnewthing/20050419-50/?p=35853

By default, Explorer does not show files that have the FILE_ATTRIBUTE_HIDDEN flag, since somebody went out of their way to hide those files from view.

通常情况下,资源管理器不会显示带有 FILE_ATTRIBUTE_HIDDEN 标签的文件,因为有人特意将这些文件在视图中隐藏了。

You can, of course, ask that such files be shown anyway by going to Folder Options and selecting “Show hidden files and folders”. This shows files and folders even if they are marked as FILE_ATTRIBUTE_HIDDEN.

当然,你也可以刻意要求将这些文件显示出来,方法是在『文件夹选项』中勾选『显示隐藏的文件和文件夹』。这样即便被标记了 FILE_ATTRIBUTE_HIDDEN 标签的文件和文件夹也会被显示出来。

On the other hand, files that are marked as both FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM remain hidden from view. These are typically files that involved in the plumbing of the operating system, messing with which can cause various types of “excitement”. Files like the page file, folder configuration files, and the System Volume Information folder.

另一方面,同时具有 FILE_ATTRIBUTE_HIDDEN  和 FILE_ATTRIBUTE_SYSTEM 标签的文件在视图中仍然是隐藏的,这类文件通常是对系统来说至关重要的,对这些文件乱来会造成各种各样『激动人心』的事情,例如页面文件(译注:虚拟内存)、文件夹的配置文件、以及卷信息(System Volumn Information)文件夹。

If you want to see those files, too, then you can uncheck “Hide protected operating system files”.

如果你想看到这些文件,可以选择取消勾选『隐藏受保护的系统文件』。

Let’s look at how far this game of hide/show ping-pong has gone:

现在我们来看看这场隐藏与显示猫鼠游戏走到了什么地步:

Show(显示) Hide(隐藏)
1. Normal file(普通文件)
2. Hidden file(带有隐藏属性的文件)
3. “Show hidden files”(『显示隐藏的文件(和文件夹)』)
4. Hidden + System(带有隐藏+系统属性的文件(和文件夹))
5. “Show protected
operating system files”(『显示受保护的系统文件』)

You’d think this would be the end of the hide/show arms race, but apparently some people want to add a sixth level and make something invisible to Explorer, overriding the five existing levels.

你可能以为这场隐藏与现实的军备竞赛就到此为止了,但很显然,有人还想再加一个第六级别,让某些东西在资源管理器中不可见,凌驾于现有的五层设计之上。

At some point this back-and-forth has to stop, and for now, it has stopped at level five. Adding just a sixth level would create a security hole, because it would allow a file to hide from the user. As a matter of security, a sufficiently-privileged user must always have a way of seeing what is there or at least know that there is something there that can’t be seen. Nothing can be undetectably invisible.

这种你来我往的竞赛到了某种程度就应该打住了,而目前则停在了第五级上。只增加一个第六级会催生一个安全漏洞,因为那样就会允许某个文件对用户不可见。出于安全考虑,某个具备足够权限的用户必须总是有办法看到某处有什么东西,或者至少知道那里有什么目前看不到的东西。任何东西完全隐形、无法被检测到是不可以的。

If you add a sixth level that lets a file hide from level five, then there must be a level seven that reveals it.

如果你真的增加了在第五级的情况下看不到的第六级,那么就必须有第七级可以解除这种限制。

TONT 36053 程序向你抛出了一个问题,但如果作答的话就会爆炸

原文链接:https://devblogs.microsoft.com/oldnewthing/20050328-00/?p=36053

JeffDav’s story of a program that didn’t like it when he told it where to install reminded me of another program that we dealt with during Windows 95 development.

JeffDav 上那篇关于某个不喜欢被用户指定安装位置的程序的故事,让我想起我们在 Windows 95 开发过程中曾经面对的另一个程序。

This was a big-name program developed by one of the biggest-of-the-big name software companies. Let’s give this program the imaginary name “LitWare”. Its setup program asked you where you wanted the program to be installed, and it suggested “C:\LITWARE”. If you accepted the default, then everything proceeded normally.

那个程序是某个顶尖有名的大公司开发的某个大品牌,这里我们先给它起个虚构的名字,叫 LitWare。这个应用的安装程序会询问你要将其安装到哪个位置,并顺带建议安装到『C:\LITWARE』。如果你直接采纳这个默认值,那么一切都会很顺利。

However, if you changed the default to anything else, the setup program ran to completion, but the program itself wouldn’t run.

然而,如果你把这个默认值改成其它的路径,那么虽然可以完成安装,但程序本身则无法启动。

Because the program contained the hard-coded path “C:\LITWARE” and insisted that it find its support files in that directory.

因为程序里将路径『C:\LITWARE』进行了硬编码,并坚持在那个路径下面寻找程序的支持文件。

At least Jeff’s program realized that it was about to be installed into a directory where it would fail to work!

至少 Jeff 提到的那个程序还晓得自己要被安装到会造成它没法工作的目录里去呢!

 

附:文章开头提到的 JeffDav 上的文章:《安装的麻烦》(Installation woes)

原文链接:https://docs.microsoft.com/en-us/archive/blogs/jeffdav/installation-woes

After successfully getting Windows XP SP2 installed on my laptop, I started installing other software.

在成功把 Windows XP SP2 安装到我笔记本上之后,我开始安装其它的程序。

This post has nothing to do with IE, but I need to vent.

这篇博文跟 IE 没什么关系,但我还是得发泄一下。

Nameless 3rd Party App: Where do you want to install me? How about c:\nameless?

某第三方应用:你要把我安装到什么地方?C:\nameless 这个路径怎么样?

Jeffdav: How about c:\program files\nameless?

Jeffdav:C:\Program Files\nameless 怎么样?

Nameless 3rd Party App: It is a bad idea to install me somewhere with spaces in the path. Continue anyway?

某第三方应用:把我装到路径里有空格的位置可不是个好主意,还是要继续吗?

Jeffdav: No. Lame. At least it knows it is lame and told me while I still have a chance to do something about it.

Jeffdav:不,算了吧。至少它还知道这样会出事,把这件事告诉了我,让我还有机会做点改变。

Jeffdav: Okay, fine, c:\nameless.

Jeffdav:行吧,那就这样,C:\nameless。

(译注:下面是另一个故事)

Nameless Microsoft App: Installing…

某微软应用:正在安装……

Nameless Microsoft App: Installing… <30 minutes later>

某微软应用:正在安装……(30分钟之后)

Microsoft Windows: You have lost your connection to the wireless LAN! (I was walking to a meeting.)

Windows:无线网络连接不可用!(我正在端着笔记本去开会的路上)

Nameless Microsoft App: Internal Error 3452. [OK]

某微软应用:内部错误3452。(点OK)

Microsoft Windows: You have reconnected to the wireless LAN!

Windows:无线网络已连接!

Jeffdav: <clicks OK>

Jeffdav:(点OK)

Nameless Microsoft App: Uninstalling…

某微软应用:正在卸载……

Nameless Microsoft App: Thanks for playing. Please start from the beginning again.

某微软应用:胜败乃兵家常事,大侠请重新来过。

Of course I did have success stories. Windows was easy to install off the slipstream CD. Putty, as always, was easy to install since setup for putty is simply xcopy.

当然我也成功安装过其它的程序。Windows 从整合好的光盘上安装很简单。Putty 则是一如既往的简单,毕竟只是一行 xcopy 的事。

The moral of this story, I guess, is that Setup is Hard.

我想,这个故事的寓意大概是,安装这件事真难啊。

TONT 36183 窗体不是便宜的对象

原文链接:https://devblogs.microsoft.com/oldnewthing/20050315-00/?p=36183

(译注:我深知这一篇的翻译质量应该很差,看不下去的话请直接跳过……)

Although Windows is centered around, well, windows, a window itself is not a cheap object. What’s more, the tight memory constraints of systems of 1985 forced various design decisions.

尽管 Windows 是围绕着窗体(windows)设计的,不过窗体并不是便宜大把的对象。此外,1985年硬件配置中紧俏的内存限制催生了很多被迫的设计决定。

Let’s take for example the design of the list box control. In a modern design, you might design the list box control as accepting a list of child windows, each of which represents an entry in the list. A list box with 20,000 items would have 20,000 child windows.

以 Listbox 控件的设计为例。在如今的设计理念中,你可能会将其设计为包含一列子窗体的控件,每个子窗体代表列表中的一个条目。一个拥有20000项条目的 Listbox 就会有20000个子窗体。

That would have been completely laughable in 1985.

这种设计在1985年会让人笑掉大牙。

Recall that Windows was built around a 16-bit processor. Window handles were 16-bit values and internally were just near pointers into a 64K heap. A window object was 88 bytes (I counted), which means that you could squeeze in a maximum of 700 or so before you ran out of memory. What’s more, menus hung out in this same 64K heap, so the actual limit was much lower.

回忆一下,当时 Windows 是围绕16位处理器设计的。窗体句柄是一系列16位的值,在内部则表现为一个 64K 堆中相邻的指针。一个窗体对象要用掉88个字节(我数过了),这就意味着你最多能在内存里塞下700个窗体,再塞就要内存溢出了。另外,菜单也在同一个 64K 堆中,故而实际的上限可能会更低。

Even if the window manager internally used a heap larger than 64K (which Windows 95 did), 20,000 windows comes out to over 1.5MB. Since the 8086 had a maximum address space of 1MB, even if you devoted every single byte of memory to window objects, you’d still not have enough memory.

即便窗体管理器在内部使用的是一个大于 64K 的堆(Windows 95即是如此),20000个窗体也要消耗将近 1.5MB 的空间。由于 8086 处理器的地址空间上限是 1MB,就算你将内存的每一个字节都贡献给窗体对象使用,还是没有足够的内存可以用。

Furthermore, making each list box item a window means that every list box would be a variable-height list box, which carries with it the complexity of managing a container with variable-height items. This goes against two general principles of API design: (1) simple things should be simple, and (2) “pay-for-play”, that if you are doing the simple thing, you shouldn’t have to pay the cost of the complex thing.

除此之外,让每一个 Listbox 的项目都作为一个窗体,意味着每个 Listbox 都会是高度可变的,这就带来了管理包含着可变高度项目的容器的复杂性。如此的设计违背了 API 设计的两项基本原则:(1)简单的事物就应该简单,以及(2)『办多少事花多少钱』,也就是如果事情本身就很简单,便不应当为复杂的事情付出代价。

Filling a list box with actual windows also would have made the “virtual list box” design significantly trickier. With the current design, you can say, “There are a million items” without actually having to create them.

将一个 Listbox 填满事实意义上的窗体,也会将这个『虚拟 Listbox』的设计变得陡然复杂起来。按照其目前的设计,你可以声明『列表中有一百万项』,但不必实际去创建这么多项目。

(This is also why the window space is divided into “client” and “non-client” areas rather than making the non-client area consist of little child windows.)

(这也是为什么窗体控件被分割为『工作区』和『非工作区』,而不是让非工作区也填满了小小的子窗体的缘故。)

To maintain compatibility with 16-bit Windows programs (which still run on Windows XP thanks to the WOW layer), there cannot be more than 65536 window handles in the system, because any more than that would prevent 16-bit programs from being able to talk meaningfully about windows. (Once you create your 65537’th window, there will be two windows with the same 16-bit handle value, thanks to the pigeonhole principle.)

为了维持与16位Windows应用程序的兼容性(鉴于WOW(译注:Windows-On-Windows,在新版Windows上为面向旧版系统设计的应用程序提供有限兼容性的兼容层,此处为32位系统兼容16位应用程序)层,这些程序在 Windows XP 上仍然可用),系统中的窗体句柄不能超过65536个,因为超过这个限制会阻止16位应用程序与系统对窗体进行有意义的沟通。(一旦创建了第65537个窗体,就会出现具有相同句柄值的两个窗体——感谢鸽巢原理(译注:又叫抽屉原理,指如果尝试将n+1个元素放进n个集合中,那么必然有一个集合中包含2个元素)的存在。)

(And yes, 16/32-bit interoperability is still important even today.)

(另外没错,16/32位应用程序的交互操作性,时至今日仍然很重要。)

With a limit of 65536 window handles, your directory with 100,000 files in it would be in serious trouble.

鉴于65535个窗体句柄上限的存在,你那拥有10万个文件的目录(如果按照前面那样嵌套小窗体的设计)就会有大麻烦了。

The cost of a window object has grown over time, as new features get added to the window manager. Today it’s even heftier than the svelte 88 bytes of yesteryear. It is to your advantage not to create more windows than necessary.

随着新功能不断加入窗体管理器,窗体对象的成本也在不断攀升。如今窗体数据的健壮程度已与当年那个苗条的88字节大小不可同日而语,而不要创建多于必要的窗体的责任就落在了你的肩上。

If your application design has you creating thousands of windows for sub-objects, you should consider moving to a windowless model, like Internet Explorer, Word, list boxes, treeview, listview, and even our scrollbar sample program. By going windowless, you shed the system overhead of a full window handle, with all the baggage that comes with it. Since window handles are visible to all processes, there is a lot of overhead associated with centrally managing the window list. If you go windowless, then the only program that can access your content is you. You don’t have to worry about marshalling, cross-process synchronization, Unicode/ANSI translation, external subclassing, hooks… And you can use a gigabyte of memory to keep track of your windowless data if that’s what you want, since your windowless controls don’t affect any other processes. The fact that window handles are accessible to other processes imposes a practical limit on how many of them can be created without impacting the system as a whole.

如果你的程序设计需要你创建成千上万个用于内部对象的窗体,你应当考虑迁移到无窗体的模型,就像 Internet Explorer、Word、Listbox、TreeView、ListView,甚至我们的滚动条示例程序那样。通过使用无窗体设计,你的程序向系统展示的就只有一个完整的窗体句柄,里面包含着所有大大小小的元素。由于窗体句柄是对所有进程可见的,对于集中管理的窗体列表来说负担是很重的。如果采用无窗体设计,那么唯一可以访问窗体中内容的就是你自己。你不必担心 Marshalling、跨进程同步、Unicode/ANSI 转换、外部子类、钩子…… 等等的麻烦事。另外如果你愿意,动用一个G的内存来跟踪你的无窗体模型下的内容也是刻意的,因为你的无窗体模型中的控件不会影响其它进程。由于窗体句柄对其他进程是可见的,也就对可以创建多少个窗体句柄而不会对系统整体产生重大影响这一事实施加了影响。

I believe that WinFX uses the “everything on the screen is an element” model. It is my understanding that they’ve built a windowless framework so you don’t have to. (I’m not sure about this, though, not being a WinFX person myself.)

我相信 WinFX 利用了『屏幕上的一切都是元素』这种模型,我的理解是他们构建了一个无窗体框架,以便你不用再从头造一遍轮子。(尽管对此我并不确定,毕竟我不是相关人士。)