26,844 reputation
1061140
bio website linkedin.com/in/avidouglen
location Israel
age 39
visits member for 3 years, 5 months
seen 21 mins ago

Security expert and experienced Windows programmer


Dec
23
comment Security review: “HTTP header user-agent has been set to (something)”
But then, the vuln should say that! At least, something about session management. It reads more like they have no idea how HTTP works...
Dec
23
comment Security review: “HTTP header user-agent has been set to (something)”
What @Ams said - but I'd go even further and say that whoever did this review is either clueless, or full of crap. Unless they explain it satisfactorily (I have no clue how) - I would say to make a stink. Folks like that give the rest a bad name. (Whats the joke about lawyers? 98% of them give the rest a bad name?)
Dec
23
revised Can you secure a web app from FireSheep without using SSL?
edited tags
Dec
23
answered Escaping JavaScript constants
Dec
23
revised Escaping JavaScript constants
edited tags
Dec
23
revised logging requirements for PCI for web applications
edited tags
Dec
22
awarded  Nice Question
Dec
21
comment Securing the security guy's home office: what should we do?
@Rory, I agree. Your security guy should be trustworthy, and reliable. Trustworthy to not do bad things, and reliable to know what the right thing to do is. And reliable enough to know the areas he's NOT an expert in (e.g. hardening OS), and rely on someone who is. (That said, I do find the sarcasm and potential infinite loop to be mildly amusing...)
Dec
20
comment Fortify360 - Sinks & Sources - Vulnerability count
One point should be noted, you shouldnt be fixing the 300 XSS instances in the same location, where you pull your data. XSS is inherently an output format flaw, not a data flaw. You can't fix the data, until you know the context of the output. For example, what if the same piece of data is displayed once in a TD, once as the value attribute of an INPUT, another time inside XML, and once it's even used to dynamically generate javascript. Each time it would need to be encoded differently, depending on the context.
Dec
20
comment Whitelisting DOM elements to defeat XSS
Yes, but enough? Is it worth it? I think that as it is, there are already enough solutions out there. And while I definitely think its worthwhile finding ways to make it easier for developers to solve their own XSS issues, in most cases I find that actually fixing the issues take less time than analyzing the discovered vulns to decide which way to fix it. So, even with your solution, you'd still be doing a lot of analysis, to figure out which elements can be whitelisted, and which should be validated...
Dec
20
comment Whitelisting DOM elements to defeat XSS
@jweyrich, but you'd still have the same vulnerabilities for the list of elements you whitelisted. Doesnt mean you're gonna go back and fix all of THOSE.
Dec
20
revised Whitelisting DOM elements to defeat XSS
edited tags
Dec
20
comment Session Hijacking - regenerate session ID
+1, except for one very important detail : random and unguessable tokens does not include GUIDs. GUID is inherently NOT secure for session ids. Please please change that...
Dec
20
comment Session Hijacking - regenerate session ID
Removed the PHP tag, since this question is applicable regardless of the implementation language.
Dec
20
revised Session Hijacking - regenerate session ID
edited tags
Dec
20
revised War dial research
edited tags
Dec
20
awarded  Nice Answer
Dec
20
comment Securing an E-commerce site
@Ams of course I agree with the further steps, however thats not what @jeremy was asking for... Perhaps if you emphasized this as advice for the future... I meant that you cannot make an app secure simply by testing.
Dec
20
comment What risk analysis methodologies should I use?
Have link? How does it compare to FAIR?
Dec
19
revised Does it matter which Certificate Authority I source my SSL Certificate from?
added 2 characters in body