Comments on: New Terminology http://www.gnucitizen.org/blog/new-terminology/ Information Security Think Tank Sun, 23 Nov 2008 17:23:51 +0000 http://wordpress.org/?v=2.6.3 By: pdp http://www.gnucitizen.org/blog/new-terminology/#comment-123912 pdp Wed, 01 Oct 2008 08:46:18 +0000 http://www.gnucitizen.org/?p=1021#comment-123912 vahur, IMHO context scripting is the more generic name which describes all types of CSRF vulnerabilities. however, it is not up to me to make you use any new terminologies. vahur, IMHO context scripting is the more generic name which describes all types of CSRF vulnerabilities. however, it is not up to me to make you use any new terminologies.

]]> By: vahur http://www.gnucitizen.org/blog/new-terminology/#comment-123896 vahur Tue, 30 Sep 2008 07:06:30 +0000 http://www.gnucitizen.org/?p=1021#comment-123896 Cross-site Request Forgery suites just fine, no need for page/context/frame/... Cross-site Request Forgery suites just fine, no need for page/context/frame/…

]]> By: Alcance Libre - Miguel Justo: Nueva Terminología surgida de Black Hat 2008. http://www.gnucitizen.org/blog/new-terminology/#comment-123196 Alcance Libre - Miguel Justo: Nueva Terminología surgida de Black Hat 2008. Tue, 05 Aug 2008 15:00:26 +0000 http://www.gnucitizen.org/?p=1021#comment-123196 [...] personal de Miguel Justo, encontramos un interesante texto, basado sobre una publicación en Gnucitizen, acerca de nueva terminología surgida de la conferencia de seguridad técnica Black Hat 2008 y que [...] [...] personal de Miguel Justo, encontramos un interesante texto, basado sobre una publicación en Gnucitizen, acerca de nueva terminología surgida de la conferencia de seguridad técnica Black Hat 2008 y que [...]

]]> By: Yousif http://www.gnucitizen.org/blog/new-terminology/#comment-123192 Yousif Tue, 05 Aug 2008 00:39:04 +0000 http://www.gnucitizen.org/?p=1021#comment-123192 That's not too bad, at least it's not like Commercial, off-the-shelf (COTS) -- That's so annoying. Expanding unnecessary terminology is annoying. That’s not too bad, at least it’s not like Commercial, off-the-shelf (COTS) — That’s so annoying. Expanding unnecessary terminology is annoying.

]]> By: pdp http://www.gnucitizen.org/blog/new-terminology/#comment-123190 pdp Mon, 04 Aug 2008 20:35:06 +0000 http://www.gnucitizen.org/?p=1021#comment-123190 you are absolutely right... and yes, not all generalizations fit everybody. so the terms are probably not the most suitable but they help me to define things I constantly see in my work. If I say that I've found an injection issue, the first question that emerges is <q>but what kind of injection issue?</q> then you have to be specific. This is where these terms come into place. From my prospective, Cross-context Scripting is much more accurate term then Cross-site Scripting, not only because the injection issue can occur between applications, not sites, but also because it fits very well to the concepts behind the same origin policies. Perhaps Cross-origin Scripting is better term. I don't know. you are absolutely right… and yes, not all generalizations fit everybody. so the terms are probably not the most suitable but they help me to define things I constantly see in my work. If I say that I’ve found an injection issue, the first question that emerges is but what kind of injection issue? then you have to be specific. This is where these terms come into place.

From my prospective, Cross-context Scripting is much more accurate term then Cross-site Scripting, not only because the injection issue can occur between applications, not sites, but also because it fits very well to the concepts behind the same origin policies. Perhaps Cross-origin Scripting is better term. I don’t know.

]]> By: rvdh http://www.gnucitizen.org/blog/new-terminology/#comment-123188 rvdh Mon, 04 Aug 2008 19:56:22 +0000 http://www.gnucitizen.org/?p=1021#comment-123188 For the sole purpose of dicussing to someone what a certain vulnerability does, such terminology is helpful granted that people still understand that there are basically two underlying principles that define pretty much al appsec problems: - input vulnerabilities For example: xss, sqli, code c.q. command injection. - unauthorized request vulnerabilities For example: CSRF, session fixation, SOP violatiions. Since these are my generalizations, I understand the need for better terminology to explain each of them 'context' based, but how do you envisage the problem with people trying to understand the type of definition that lies beneath it? I found out that the more you coin new terms, the harder for peopl it is to look beyond them and see it's context while they disregard some of the other terminology. This happened with most old school security folks who are still under the firewall syndrome, it took some of them to realize that most of the vulnerabilities in a network layer also work in the software layer, but they had different terminology c.q. definitions which made them to reject the idea of appsec dangers while at the basis it's basically the same. For the sole purpose of dicussing to someone what a certain vulnerability does, such terminology is helpful granted that people still understand that there are basically two underlying principles that define pretty much al appsec problems:

- input vulnerabilities
For example: xss, sqli, code c.q. command injection.

- unauthorized request vulnerabilities
For example: CSRF, session fixation, SOP violatiions.

Since these are my generalizations, I understand the need for better terminology to explain each of them ‘context’ based, but how do you envisage the problem with people trying to understand the type of definition that lies beneath it? I found out that the more you coin new terms, the harder for peopl it is to look beyond them and see it’s context while they disregard some of the other terminology. This happened with most old school security folks who are still under the firewall syndrome, it took some of them to realize that most of the vulnerabilities in a network layer also work in the software layer, but they had different terminology c.q. definitions which made them to reject the idea of appsec dangers while at the basis it’s basically the same.

]]>