TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Security Checklist

149 点作者 nthompson大约 9 年前

18 条评论

nmjohn大约 9 年前
There&#x27;s a problem with viewing security as a &quot;checklist&quot; problem, it treats everything as binary, black or white problem&#x2F;solutions. In reality, this is _far_ from the case. For example:<p>&gt; Is TLS1.2 the only supported protocol?<p>Do you know what the implications are from actually implementing that? One probably should do additional research before making that decision.<p>&gt; Have you ensured that your content cannot be embedded in a frame on another website?<p>X-Frame-Options isn&#x27;t the only way to achieve that.<p>&gt; Have you ensured that the Internet Explorer content sniffer is disabled?<p>This really is only relevant if your site is hosting untrusted content.<p>&gt; Are you using fail2ban to throttle ssh login attempts?<p>&gt; Have you disabled password-based login over ssh, and only allowed key-based login?<p>The first really is of debatable value if the second is also used.<p>&gt; Do forms set a cross-site request forgery cookie?<p>Cookies are not the only way to do this. More common, in my experience, is including the csrf token in the dom (either in a form field as a &quot;hidden&quot; input or as a meta tag)<p>&gt; Do you have an account recovery flow? Delete it immediately.<p>Lol.<p>It&#x27;s a great checklist for someone who knows what every item on the list is and more importantly, _why_ it is on the list - but it is not something that should be blindly followed.
评论 #11324173 未加载
评论 #11324477 未加载
评论 #11325079 未加载
评论 #11324614 未加载
评论 #11325002 未加载
msbarnett大约 9 年前
&gt; Are all form fields (with the exception of password fields) validated with a restrictive regex?<p>Please, whatever you do, do not try to regex validate people&#x27;s names. A friend couldn&#x27;t complete an order on a site the other day because it was rejecting his name as &quot;invalid&quot; per its shitty regex.<p>See also Falsehoods Programmers Believe About Names[1]<p>[1] <a href="http:&#x2F;&#x2F;www.kalzumeus.com&#x2F;2010&#x2F;06&#x2F;17&#x2F;falsehoods-programmers-believe-about-names&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.kalzumeus.com&#x2F;2010&#x2F;06&#x2F;17&#x2F;falsehoods-programmers-b...</a>
评论 #11325325 未加载
评论 #11324294 未加载
评论 #11325147 未加载
tptacek大约 9 年前
Quibbles:<p>* You&#x27;re right now fine with 2048 bit keys. The thing that jeopardizes 2048 bit keys might end up knocking RSA out entirely.<p>* There&#x27;s really no point to fail2ban if you disabled passwords for SSH, and doing that is much more important than fail2ban.<p>* The checklist item for password security should make it clear that you need a <i>password hash</i> (PBKDF2, bcrypt scrypt, Argon2), not just a &quot;hash&quot;.<p>Given the context, the only big thing that&#x27;s missing is HPKP.
评论 #11324104 未加载
评论 #11329581 未加载
评论 #11324133 未加载
elchief大约 9 年前
4096 bit RSA key is overkill and slow. 2048 is fine for years<p>You probably need to support TLS 1.1 for some older clients<p>Password entropy checks should only be used in a corporate environment. You&#x27;ll lose customers in a retail environment. You should certainly encourage your customers to use high entropy passwords, but forcing them to will just lose you money.<p>Login throttling and IP banning is a waste of time. Login throttling will just DoS yourself. You need CAPTCHA or Proof of Work.<p>Synchronizing Token (CSRF token in hidden form fields) is better than CSRF cookies<p>Use a real HTML parser (*Soup) to invalidate XSS form input not regex
评论 #11324765 未加载
评论 #11329605 未加载
koolba大约 9 年前
&gt; Do you have an account recovery flow? Delete it immediately.<p>Lol. Have fun doing this at scale for any consumer site.<p>Like everything else in security, having a password reset&#x2F;account recovery flow is a trade-off between security and convenience. For the vast majority of websites, convenience wins.
评论 #11336813 未加载
lgarron大约 9 年前
I don&#x27;t see e.g. a GitHub repo to comment on, but the HSTS header example is `Strict-Transport-Security: max-age=63072000; includeSubdomains; always`<p>`always` has no meaning, and probably indicates a typo in an nginx configuration.<p>As others have pointed out, there is other TLS advice here that you shouldn&#x27;t follow blindly, like a 4096-bit cert (especially if your intermediate is smaller) or TLS 1.2 only. Rationales and trade-off explanations would help avoid misuse of this checklist.<p>The SSL Labs checker is probably the best tool to use for all the automatable TLS checks.
评论 #11324812 未加载
评论 #11325513 未加载
garrettr_大约 9 年前
&gt; Do you have an account recovery flow? Delete it immediately.<p>What about users who need to, you know, recover their account?
评论 #11325429 未加载
foobarbecue大约 9 年前
It&#x27;d be nice if this was an actual checklist. i.e. checkboxes rather than images of a checkmark so that you could run through it.
评论 #11325042 未加载
ejcx大约 9 年前
By the way. If you aren&#x27;t well versed in web application security, don&#x27;t just blindly follow guides likes this, especially when dealing with headers. You really should learn about the technologies<p>&gt; Strict-Transport-Security: max-age=63072000; includeSubdomains; always<p>I agree. All sites should be using HTTPS only and HSTS is a great thing, but if you blindly follow this guide you might break your subdomains that don&#x27;t support HTTPS (third party or whatever crazy situation you have). The same thing goes for HPKP which tptacek suggested below.<p>There&#x27;s a right way and a very wrong way to use HPKP and if you go mucking with these headers without fully understanding them yourself you might break your site for a ton of people.
评论 #11324736 未加载
Taig大约 9 年前
What is the meaning of the last point?<p>&gt; Do you have an account recovery flow? Delete it immediately.
评论 #11324060 未加载
tptacek大约 9 年前
The &quot;account recovery flow&quot; thing is, for everyone asking, presumably an in-joke about how every application pentested for the first time ends up having some gameover flaw in its password reset.
cdevs大约 9 年前
I know the majority decision is keys over passwords but every time I hear a security issue its over keys being stolen as typical malicious programs knows the standard go to place to grab them after getting you to sudo something evil. and the next response is you have time to change them before blah blah blah but attackers don&#x27;t send you a email that says hey I have your keys! Wouldn&#x27;t fail2ban with passwords be better for those who don&#x27;t know how to manage every step of this ?
r3bl大约 9 年前
This seems great! Now, all that is needed is someone who will automate this list across X most popular websites.
Laaw大约 9 年前
Is the problem with account recovery the fact that it means &quot;deleted&quot; isn&#x27;t actually deleted?
mrmondo大约 9 年前
Good start indeed, it&#x27;d be nice to have a small open source tool to do these checks, maybe even with a simple web interface - anyone seen a simple security checklist &#x2F; analyser that&#x27;s well maintained with the latest standards?
评论 #11325457 未加载
tacone大约 9 年前
It would be nice for this to become a github repo with all the bash scripts in the page.
lolidaisuki大约 9 年前
Web server security is pretty narrow portion of all security fields.
xpinguin大约 9 年前
I could call that list deliberately malicious from user experience standpoint:<p>&gt;Are password entropy checks done during user sign-up, using, say AUTH_PASSWORD_VALIDATORS?<p>No. It&#x27;s my information to be stolen, not yours. So then it is my choice, whether to use 123 as password or not. Why should I care to manage the complex password, when I use your service eg. twice an year and have no important information there? (if you really believe that people are eager to fill website with their authentic personal info unless they do not have other options, you are probably fooling yourself).<p>The better alternative is just no registration at all :)<p>&gt;Are failed login attempts throttled and IP addresses banned after a number of unsuccessful attempts<p>So, you hadn&#x27;t listened the previous piece of advice and forced me to create password that would&#x27;ve passed through the password checker. Six months passed and now I have to remember (I really don&#x27;t want to bother with managing and storing password to your service anyway) it. As you could imagine, it takes several tries, dozen or two, maybe even three - depending on that cool password validator of yours. Do you say, that I need to use tor or have some pool of spare IP adresses just to login to your service?<p>&gt;Are all form fields (with the exception of password fields) validated with a restrictive regex?<p>Aha, start with an email and surname, polish with an address;) Then your service will make it straight to the oblivion even faster!<p>&gt;Do you have an account recovery flow? Delete it immediately.<p>Quite appropriate actually: when all tor exit nodes are banned by your login attempt throttler, that retards with severe memory impairment (whom you sometimes by mistake call &quot;clients&quot; in your marketing bullshit) still must not have a glimpse of a chance to use their account!
评论 #11324849 未加载
评论 #11324866 未加载
评论 #11328159 未加载