Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
nbpoole
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
47 ms
·
391.
▲
by
nbpoole
16y ago
I need to get better at creating these kinds of titles for my vulnerability writeups :P
392.
▲
by
nbpoole
16y ago
I'm not seeing the same behavior you're seeing. Try using $.get instead of $.ajax? Edit: I was confusing X-Requested-With and Origin. My apologies.
393.
▲
by
nbpoole
16y ago
It might not send it automatically (I don't know, I haven't tested it), but since you're the one building the XHR, you can send the header if you want. The same origin policy won't let you see the results of a cross-domain request, so it se
394.
▲
by
nbpoole
16y ago
It definitely isn't set via <script>. I know it's sent when you make an XHR request via jQuery, so I assume you can set it as a custom header if you're rolling your own XHR.
395.
▲
by
nbpoole
16y ago
You're absolutely correct. Origin or X-Requested-With (or any other custom header) are a good source of protection for cases like this.
396.
▲
by
nbpoole
16y ago
The assumption is that a browser won't let you re-define the meaning of low-level constructs like "while" and "1". The assumption is somewhat reasonable, but it could be violated in the future, which is why the Browser Security Handbook adv
397.
▲
How Does Cross-Site Scripting Become Arbitrary Code Execution?
(nealpoole.com)
3 points
by
nbpoole
16y ago
|
0 comments
398.
▲
by
nbpoole
16y ago
I just posted this on the issue: ---- I would be wary of solving the problem this way. The problem is the object/array combo you're talking about is still perfectly valid JavaScript. However, due to the way browsers handle JavaScript, it's
399.
▲
by
nbpoole
16y ago
You also have to consider the possibility of an offline attack (ie: if Amazon's database were compromised and password hashes were leaked).
400.
▲
by
nbpoole
16y ago
That depends on how fast you can check for validity. See http://news.ycombinator.com/item?id=2003888 or http://news.ycombinator.com/item?id=1545576 for examples of how fast certain types of brute-force attacks have become.
401.
▲
by
nbpoole
16y ago
"I don't think checking every hash within one of the password is going to cost much, worst case your checking less than 1,000 passwords." If that's the case, you're doing it wrong (it being password hashing). Because if you can hash 1000 pa
402.
▲
by
nbpoole
16y ago
You're right. The reason I pointed it out as a flaw is because it has major consequences in this case. It's true for every hash function, but highly unlikely to happen in most cases.
403.
▲
by
nbpoole
16y ago
Yes. Sort of. ;-) The standard way I've seen is to do this when the user logs in: if in checking their password you notice they're using the old hashing scheme, you use the plaintext password provided by the login process to generate a hash
404.
▲
by
nbpoole
16y ago
The comment thread on Reddit, which the article references, is definitely worth reading. There's some good discussion about the difficulties involved in upgrading people's hashes to use a more secure system (eg: http://www.reddit.com/r/WTF
405.
▲
by
nbpoole
16y ago
You haven't heard of any other accounts having weird status updates posted to them? Really? ;) See http://abcnews.go.com/Technology/wireStory?id=12747194
406.
▲
by
nbpoole
16y ago
That sentence was written by the author of the article: it doesn't appear to be based on what people actually said. The quote from Facebook is "A bug enabled status postings by unauthorized people on a handful of public pages. The bug has b
407.
▲
by
nbpoole
16y ago
Why? That's easy: I made a deal with Randall Munrow and as a result I'm legally obligated to post links to XKCD comics all over the web! Seriously though. I enjoy reading XKCD and the first thing I thought of when I read the title of the po
408.
▲
by
nbpoole
16y ago
Obligatory XKCD: http://xkcd.com/353/
409.
▲
by
nbpoole
16y ago
And they do so, in the form of Wordpress.com. If what you want is a blog about your dog, you can have it for free with Wordpress software that you never have to manage the code for or pay for. I have a number of friends who use it and they
410.
▲
by
nbpoole
16y ago
Well, that depends on your point of view. My personal opinion is that such a system would give people a false sense of security (since we know it's impossible for such a system to detect all malicious content) and would cause "script kiddie
411.
▲
by
nbpoole
16y ago
That's completely untrue :P You're assuming that there is some supreme Rendering Engine which maps code to a single canonical output. In reality, every browser renders things slightly differently and a malicious script would take advantage
412.
▲
by
nbpoole
16y ago
I'm a big fan of Stefan Esser, but this has no relevance to the discussion at hand. You're just regurgitating a lot of anti-PHP rhetoric.
413.
▲
by
nbpoole
16y ago
And none of these posts you're referencing are at all relevant to the issue at hand (unless you're taking the position that PHP is Pure Evil as a language, which is an entirely separate issue)! ;-) The question at hand isn't whether it's ea
414.
▲
by
nbpoole
16y ago
Automate what test? Searching for calls to base64_encode? Five minutes after they do that, people will write their own base64-encoding functions. Security by blacklist is not security at all.
415.
▲
by
nbpoole
16y ago
"If a user is already intent on removing a credit url, hiding it behind obfuscation isn't going to change their mind. As an author giving out an effectively open source theme, the only asset you can depend upon is your users' goodwill." I w
416.
▲
by
nbpoole
16y ago
These problems are not inherent to PHP. As other people have pointed out, this is what happens when you run arbitrary code on your server. Even if you took away the base64 encoding and eval calls, people could still embed spammy links into
417.
▲
by
nbpoole
16y ago
No, it doesn't. Is it shady? Yes. Would I want it running on my server? Absolutely not. Is the code running a backdoor that lets the attackers execute shell commands? We don't know. Obfuscation like this could be used for any number of thin
418.
▲
by
nbpoole
16y ago
I didn't mean a fully automated analysis (although it's possible to somewhat automate the de-obfuscation: see http://php-security.org/2010/05/13/article-decoding-a-user-s... ). But given a bit of time, it should be possible to "unwrap" the
419.
▲
by
nbpoole
16y ago
I said this in the post, but I want to make it clear here: the Origin header is not a panacea for CSRF. There are plenty of other elements that can render it useless as a form of protection, which I spell out in the post itself. However, it
420.
▲
by
nbpoole
16y ago
Ugh. I'm going to be regretting my snarky comment about the Referer header very soon :P
More ›