258 reputation
210
bio website
location
age
visits member for 2 years, 3 months
seen Jun 26 at 1:26

Apr
9
comment Implication of URL injection in an URL shortener service
I'd like to point out that I find it very very sad that most questions here gets answered with, basically: "This is a solved problem, it's very easy to do a, b and c to dodge exploit x, y or z", Yet we're seeing exploits exploiting trivial security holes daily. So it would be nice if the mindset of security-aware people would change from: "It's easy, all you need is to parse/sanitize/etc." to a more open-minded and pro-active way of thinking...
Apr
9
comment Implication of URL injection in an URL shortener service
regarding the Google safe-browsing, there's a serious misunderstanding here: I'm not very concerned about what the URL contains here (not that it's not a valid concern, but it's something else altogether), I'm concerned about the URL itself doing something nasty to my users when they're visiting my site, not when they're visiting the target URL.
Apr
9
comment Implication of URL injection in an URL shortener service
"...and the database query to save the mapping" There has to be a database query anyway to save the URL. Doesn't change anything if I'm saving the bit.ly mapping URL or the direct URL in my DB. : ) I agree that there's a price to pay for the call to the URL shortener: that's the price for added security.
Apr
9
comment Implication of URL injection in an URL shortener service
"The only security you would get from an external URL shortening service is that they will only shorten valid URLS, and not javascript code etc." But that's kinda precisely the whole point. That's quite an added security: when the latest URL injection comes out, my site ain't affected and it's the URL shortening service that needs to patch his webapp service, not me. Once again: this is not incompatible with other measure, like calling Google's safe-browsing API (also, if you call calling an URL shortener 'inefficient', I wonder what you call calling Google's verification API ; )
Apr
9
comment Implication of URL injection in an URL shortener service
"This is an inefficient way of doing things."... There are only so much URLs an user can submit and all it takes for me is to call the URL shortening service once and saving that result/mapping in my DB. What's innefficient about this?
Apr
9
comment Implication of URL injection in an URL shortener service
I think there's a misunderstanding: whatever URL the user sends, that URL first gets send by my webapp to the URL shortening service and then when I'm generating the pages to be served containing the URL the user "inputed", well, I'm not really serving back that URL. I'll only ever be serving URL starting with, say, bit.ly and then adding at most nine alphanumeric characters. I don't care where the URL the user inputs comes from: it shall go through the URL shortening service no matter what and it's the result from the URL shortening service that I shall display on my site.
Apr
9
comment Implication of URL injection in an URL shortener service
I know about OWASP, it's precisely why I'm looking for additional measure against, say, XSS. What I'm trying to determine is if in this case XSS would still be my problem or not. :-/ (I'll edit to reflect that)
Apr
9
comment Implication of URL injection in an URL shortener service
I could throttle user inputs so that I don't hammer the URL shortening service and I take it that the URL shortening service is acting in good faith. I haven't heard URL shortening services returning bad URLs on purpose :-/ Basically what I'd like to understand are the XSS / CSRF and other security implication should security be correct on my site but an exploit able to bypass the URL shortener's security (I'm not that concerned about the URL shortener being itself a rogue site but even if that service was fully hacked/rooted, what would be the implication for my site?).
Mar
11
comment Simple solution to XSS
@dr jimbob: well but it's not really "rolling my own", I'm just adding another layer of security which is not IMHO incompatible with other security measures. Moreover I could be totally public about it: it's not "security by obscurity". I more see it as "defense in depth". It's not because I'd be using such a scheme that I'd dodge the other, accepted, security practices. I may give it a try on a Java / Tomcat webapp for the fun : )
Mar
11
comment Simple solution to XSS
#cmt: if there's a XSS exploit that managed to make it to the DB then at least using the filter I suggested that exploit would be served with every single character wrapped inside tags (upon dynamically serving the webpage to the user). So, as Rook wrote, it would pose problem to the attacker's payload. Now I agree that there are contextual issues that need to be dealt with but I haven't read anything convincing me that my scheme wouldn't provide more defense in depth.
Mar
10
comment Simple solution to XSS
an already "solved" problem? Hardly a week passes by without someone finding an exploit that is yet another variation on the XSS exploit and which manages to somehow dodge all the purifier and whatnots already in place... Good point about posting URLs that said: some thoughts would need to go into that. Now I don't see how it could be "silly" when you say yourself that you're not seeing any way for an attacker to easily do XSS on such a system. It's also not mutually exclusive with a purifier and HTML escaping :-/
Mar
10
comment Simple solution to XSS
@makerofthings7: I'm thinking of serving any input sent by a user back by wrapping every single character sent by the user inside HTML tags. I wouldn't do this from JavaScript: this would be done from the server side. Single character needing HTML escaping would be escaped, of course (but they would also, just like any other character, be wrapped inside tags). So basically every character input by a user would become 8 characters (when not needing escaping) or more (when needing HTML escaping).
Jan
10
comment Can real end-to-end SSL encryption be made?
ah ok I see, thanks for answering about that part in detail... So I guess the situation is not too bad regarding the ISP issue. I'll now go read upon Chrome / Chromium and certificates ; )
Jan
10
comment Can real end-to-end SSL encryption be made?
I'm +1'ing everyone for their time and great answer... However, when you say you look at the certificate issuer, how often do you do that? Once after you install the browser? Everytime you connect to your bank's online website (I do that twice per month or so, so I wouldn't mind checking at that time)? Can't / Won't the browser like Chrome (or Chromium?) silently install new certificates without asking you first? If the browser cannot add new certificates without asking you, then I take it a live-CD created from known sources used for online banking is pretty safe.
Jan
10
comment Can real end-to-end SSL encryption be made?
@makerofthings7: user 'Thomas Pornin' in his answer below gave two links... Apparently I was correct about Nokia but Opera Mini claims they only do it for HTTP, not HTTPS.
Jan
10
comment Can real end-to-end SSL encryption be made?
@CodesInChaos: I know it's a kind of MITM ; ) I specifically wrote: "It's not MITM over SSL" in that the SSL part itself is not affected by a MITM: the SSL has still only two endpoints and nobody is listening between the two... Don't know if it makes sense, I should have been clearer :-/
Sep
27
comment Should you care about DoS attacks if your server is using bcrypt?
@schroeder: I meant to ask if a server is particularly vulnerable to DoS attacks trying to max out the CPU seen that bcrypt is particularly CPU intensive. I'm concerned because DoS attacks trying to max out the CPU (instead of the bandwith) do definitely exist: late 2011 there was the famous PHP / Java hashmap SNAFU were a few long GET URLs with crafted parameters could take down most PHP and Java servers. I don't agree that every server is vulnerable to a DoS: every server is vulnerable to a DDoS, not a simple DoS. If anyone with an IP can DoS your server you're in big trouble.