笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
自我点赞的漏洞：一次对Hacker News投票机制的幽默实验
通过构造特殊URL，让一篇帖子在Hacker News上为自己投票，揭示了投票系统缺乏来源校验的漏洞。
背景：Hacker News的投票机制
Hacker News（HN）是Y Combinator旗下的技术新闻社区，其核心互动机制就是“upvote”（点赞）。每个注册用户对每篇帖子或每条评论只能投一票，而且系统会记录投票者身份，防止重复投票。正常情况下，用户点击帖子下方的“▲”箭头，浏览器会向服务器发送一个POST请求，其中包含帖子ID、投票方向（up/down）以及用户身份凭证。
HN的投票URL格式如下：
http://news.ycombinator.com/vote?for=帖子ID&dir=up&whence=来源页
其中for参数指定目标帖子，dir指定投票方向（up为点赞），whence是一个编码后的来源URL，用于投票完成后跳转回原页面。这个whence参数通常被URL编码，看起来像%6e%65%77%65%73%74（即"newest"）。
漏洞发现：自我投票
作者在测试中发现，HN的投票接口只校验了for参数指向的帖子ID，但没有校验投票者是否是该帖子的作者。这意味着，只要构造一个特殊的URL，让帖子的作者自己点击（或通过脚本自动请求），就能给自己的帖子投票。
更妙的是，作者将whence参数设置为newest（最新帖子列表），这样当投票完成后，页面会跳转到“最新”列表，而不是返回原帖，从而掩盖了这次操作的痕迹。
实际演示
作者在HN上发布了一篇标题为“Show HN: This up votes itself”的帖子，并附带了以下链接：
http://news.ycombinator.com/vote?for=3742902&dir=up&whence=%6e%65%77%65%73%74
任何点击这个链接的用户（包括作者自己）都会对帖子ID为3742902的帖子投上一票。由于系统没有检查投票者身份与帖子作者的关联，作者通过自己点击（或写脚本模拟）就能无限次给自己投票。
技术细节分析
这个漏洞的本质是缺少服务端的状态校验。HN的投票系统假设了以下条件：
- 每个用户只能投一票（通过用户ID+帖子ID唯一约束实现）
- 用户不能给自己的帖子投票（通过检查帖子作者ID与当前用户ID是否一致实现）
但实际代码中，第2点被遗漏了。更严重的是，投票接口没有限制同一IP的请求频率，也没有使用CSRF令牌（因为HN是2006年上线的老系统，当时Web安全实践还不成熟）。这意味着：
- 一个用户可以通过脚本循环调用该URL，实现刷票
- 甚至不需要登录状态（如果系统允许匿名投票的话，但HN要求登录）
影响与后果
这个漏洞的实际影响有限，因为：
- HN的排名算法（基于时间衰减和票数）会限制刷票的长期效果
- 管理员可以手动移除异常投票
- 社区有“flag”机制来标记可疑内容
但它揭示了一个普遍问题：即使是成熟的科技社区，也可能存在基础的身份验证漏洞。HN作为Y Combinator旗下的明星产品，其代码库历史悠久，安全审查可能不如现代项目严格。
作者的意图
作者在标题中直接点明“This up votes itself”，这是一种“白帽”行为——通过公开演示来提醒HN团队修复漏洞。HN创始人Paul Graham（或当时的管理员）看到后，大概率会迅速修复该问题。事实上，这类漏洞在HN历史上出现过多次，每次都被公开报道后快速修复。
对现代Web开发的启示
- 永远不要信任客户端参数：
for参数可以被任意修改，服务端必须验证其合法性 - 所有敏感操作都需要身份校验：投票、删除、修改等操作必须确认当前用户有权限
- CSRF防护不可省略：即使是老系统，也应该用Token或SameSite Cookie来防止跨站请求
- 速率限制是必要的：即使每个请求合法，高频请求也可能表示异常行为
结局
这个帖子在HN上获得了3531分（考虑到这是自我投票的极限测试，实际票数可能远高于正常帖子），评论82条。大多数评论者以幽默的态度看待这件事，也有人认真讨论了HN的安全实践。可以推测，HN团队很快修复了这个漏洞（可能增加了作者ID校验），但这一事件已成为HN社区的一个经典彩蛋。
原文链接
http://news.ycombinator.com/vote?for=3742902&dir=up&whence=%6e%65%77%65%73%74