|
Posted
about 13 years
ago
by
Frédéric Buclin
Yesterday (23 hours ago, to be exact), we released new versions of Bugzilla which all include fixes for critical security vulnerabilities. The most critical one is described in CVE-2010-4568 and you can get the patches from bug 621591 for all versions of Bugzilla 3.2 and newer. This means that we provided no patch for Bugzilla [...]
|
|
Posted
over 13 years
ago
by
avatraxiom
Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to
... [More]
protect their applications from it.In short, here's what you need to know:Never allow unsanitized user data into HTTP headers.Most of the time, if you're using some HTTP framework, it should be handling this for you. So mostly you just need to make sure that you have a good HTTP library that security-checks its header output properly. But if you're printing headers directly to the user, as plain text (as I've seen many PHP apps do), you do need to be concerned about this.In particular, it's most important that you never allow any character that might be considered a "newline" into your HTTP headers. To understand why, and what could be dangerous about this, you need to know a little bit about HTTP. Let's say that we're sending a response to the user that looks like this:200 OK
X-My-Header: some_user_data
Content-Type: text/html; charset=UTF-8
Okay, pretty simple. This is a page that has "Hello World!" as the title, and no content. Harmless. However, what's that X-My-Header: some_user_data there? Let's imagine that some_user_data can be anything that the user input, and he inputs a string that looks like:some data;
Content-Type: text/html; charset=UTF-8
Now, your response looks like:200 OK
X-My-Header: some data;
Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
And I could have inserted anything! It's not just like a normal Cross-Site Scripting vulnerability, where I can only insert a small dangerous piece of HTML into an already-existing page. I could insert any HTML, any script, or any content at all. That content could be an ActiveX control for Internet Explorer, it could be some other content that your system is already configured to open automatically--anything. I'm not limited just to HTML or JavaScript. There's also a good chance that any Set-Cookie headers will become a part of the body instead of being part of the headers, too, so I can steal cookies even if they're marked "httponly".For the most part, this vulnerability is prevented if you never allow people to insert a CR or LF character into headers. There's no good reason to allow inserting those characters directly into a single header, so you should be pretty safe to just completely deny those characters in HTTP headers generated by your application.-Max [Less]
|
|
Posted
over 13 years
ago
Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to
... [More]
protect their applications from it.In short, here's what you need to know:Never allow unsanitized user data into HTTP headers.Most of the time, if you're using some HTTP framework, it should be handling this for you. So mostly you just need to make sure that you have a good HTTP library that security-checks its header output properly. But if you're printing headers directly to the user, as plain text (as I've seen many PHP apps do), you do need to be concerned about this.In particular, it's most important that you never allow any character that might be considered a "newline" into your HTTP headers. To understand why, and what could be dangerous about this, you need to know a little bit about HTTP. Let's say that we're sending a response to the user that looks like this:200 OK
X-My-Header: some_user_data
Content-Type: text/html; charset=UTF-8
<html><head><title<Hello World!</title><body></body></html>Okay, pretty simple. This is a page that has "Hello World!" as the title, and no content. Harmless. However, what's that X-My-Header: some_user_data there? Let's imagine that some_user_data can be anything that the user input, and he inputs a string that looks like:some data;
Content-Type: text/html; charset=UTF-8
<script type="text/javascript">all_your_base();</script>Now, your response looks like:200 OK
X-My-Header: some data;
Content-Type: text/html; charset=UTF-8
<script type="text/javascript">all_your_base();</script>
Content-Type: text/html; charset=UTF-8
<html><head><title<Hello World!</title><body></body></html>And I could have inserted anything! It's not just like a normal Cross-Site Scripting vulnerability, where I can only insert a small dangerous piece of HTML into an already-existing page. I could insert any HTML, any script, or any content at all. That content could be an ActiveX control for Internet Explorer, it could be some other content that your system is already configured to open automatically--anything. I'm not limited just to HTML or JavaScript. There's also a good chance that any Set-Cookie headers will become a part of the body instead of being part of the headers, too, so I can steal cookies even if they're marked "httponly".For the most part, this vulnerability is prevented if you never allow people to insert a CR or LF character into headers. There's no good reason to allow inserting those characters directly into a single header, so you should be pretty safe to just completely deny those characters in HTTP headers generated by your application.-Max [Less]
|
|
Posted
over 13 years
ago
Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to
... [More]
protect their applications from it.In short, here's what you need to know:Never allow unsanitized user data into HTTP headers.Most of the time, if you're using some HTTP framework, it should be handling this for you. So mostly you just need to make sure that you have a good HTTP library that security-checks its header output properly. But if you're printing headers directly to the user, as plain text (as I've seen many PHP apps do), you do need to be concerned about this.In particular, it's most important that you never allow any character that might be considered a "newline" into your HTTP headers. To understand why, and what could be dangerous about this, you need to know a little bit about HTTP. Let's say that we're sending a response to the user that looks like this:200 OK
X-My-Header: some_user_data
Content-Type: text/html; charset=UTF-8
<html><head><title<Hello World!</title><body></body></html>Okay, pretty simple. This is a page that has "Hello World!" as the title, and no content. Harmless. However, what's that X-My-Header: some_user_data there? Let's imagine that some_user_data can be anything that the user input, and he inputs a string that looks like:some data;
Content-Type: text/html; charset=UTF-8
<script type="text/javascript">all_your_base();</script>Now, your response looks like:200 OK
X-My-Header: some data;
Content-Type: text/html; charset=UTF-8
<script type="text/javascript">all_your_base();</script>
Content-Type: text/html; charset=UTF-8
<html><head><title<Hello World!</title><body></body></html>And I could have inserted anything! It's not just like a normal Cross-Site Scripting vulnerability, where I can only insert a small dangerous piece of HTML into an already-existing page. I could insert any HTML, any script, or any content at all. That content could be an ActiveX control for Internet Explorer, it could be some other content that your system is already configured to open automatically--anything. I'm not limited just to HTML or JavaScript. There's also a good chance that any Set-Cookie headers will become a part of the body instead of being part of the headers, too, so I can steal cookies even if they're marked "httponly".For the most part, this vulnerability is prevented if you never allow people to insert a CR or LF character into headers. There's no good reason to allow inserting those characters directly into a single header, so you should be pretty safe to just completely deny those characters in HTTP headers generated by your application.-Max [Less]
|
|
Posted
over 13 years
ago
Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to
... [More]
protect their applications from it.In short, here's what you need to know:Never allow unsanitized user data into HTTP headers.Most of the time, if you're using some HTTP framework, it should be handling this for you. So mostly you just need to make sure that you have a good HTTP library that security-checks its header output properly. But if you're printing headers directly to the user, as plain text (as I've seen many PHP apps do), you do need to be concerned about this.In particular, it's most important that you never allow any character that might be considered a "newline" into your HTTP headers. To understand why, and what could be dangerous about this, you need to know a little bit about HTTP. Let's say that we're sending a response to the user that looks like this:200 OK
X-My-Header: some_user_data
Content-Type: text/html; charset=UTF-8
Okay, pretty simple. This is a page that has "Hello World!" as the title, and no content. Harmless. However, what's that X-My-Header: some_user_data there? Let's imagine that some_user_data can be anything that the user input, and he inputs a string that looks like:some data;
Content-Type: text/html; charset=UTF-8
Now, your response looks like:200 OK
X-My-Header: some data;
Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
And I could have inserted anything! It's not just like a normal Cross-Site Scripting vulnerability, where I can only insert a small dangerous piece of HTML into an already-existing page. I could insert any HTML, any script, or any content at all. That content could be an ActiveX control for Internet Explorer, it could be some other content that your system is already configured to open automatically--anything. I'm not limited just to HTML or JavaScript. There's also a good chance that any Set-Cookie headers will become a part of the body instead of being part of the headers, too, so I can steal cookies even if they're marked "httponly".For the most part, this vulnerability is prevented if you never allow people to insert a CR or LF character into headers. There's no good reason to allow inserting those characters directly into a single header, so you should be pretty safe to just completely deny those characters in HTTP headers generated by your application.-Max [Less]
|
|
Posted
over 13 years
ago
Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to
... [More]
protect their applications from it.In short, here's what you need to know:Never allow unsanitized user data into HTTP headers.Most of the time, if you're using some HTTP framework, it should be handling this for you. So mostly you just need to make sure that you have a good HTTP library that security-checks its header output properly. But if you're printing headers directly to the user, as plain text (as I've seen many PHP apps do), you do need to be concerned about this.In particular, it's most important that you never allow any character that might be considered a "newline" into your HTTP headers. To understand why, and what could be dangerous about this, you need to know a little bit about HTTP. Let's say that we're sending a response to the user that looks like this:200 OK
X-My-Header: some_user_data
Content-Type: text/html; charset=UTF-8
Okay, pretty simple. This is a page that has "Hello World!" as the title, and no content. Harmless. However, what's that X-My-Header: some_user_data there? Let's imagine that some_user_data can be anything that the user input, and he inputs a string that looks like:some data;
Content-Type: text/html; charset=UTF-8
Now, your response looks like:200 OK
X-My-Header: some data;
Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
And I could have inserted anything! It's not just like a normal Cross-Site Scripting vulnerability, where I can only insert a small dangerous piece of HTML into an already-existing page. I could insert any HTML, any script, or any content at all. That content could be an ActiveX control for Internet Explorer, it could be some other content that your system is already configured to open automatically--anything. I'm not limited just to HTML or JavaScript. There's also a good chance that any Set-Cookie headers will become a part of the body instead of being part of the headers, too, so I can steal cookies even if they're marked "httponly".For the most part, this vulnerability is prevented if you never allow people to insert a CR or LF character into headers. There's no good reason to allow inserting those characters directly into a single header, so you should be pretty safe to just completely deny those characters in HTTP headers generated by your application.-Max [Less]
|
|
Posted
over 13 years
ago
by
Frédéric Buclin
If you are curious to know the version running on some well known Bugzilla installations worldwide, I collected this information in a single place: http://lpsolit.wordpress.com/bugzilla-usage-worldwide/. I think this way of doing it is better than
... [More]
writing a new article each summer, as I did for the last three years. This page also lists the approximate [...] [Less]
|
|
Posted
over 13 years
ago
by
Frédéric Buclin
Last night, we released Bugzilla 4.0rc1 and Bugzilla 3.6.3, as well as security-fixes only 3.4.9 and 3.2.9. Bugzilla 4.0rc1 comes 3 months after our latest development snapshot 3.7.3, and is considered stable enough for use in non-critical
... [More]
environments. If nothing serious is found in this release candidate, we will release Bugzilla 4.0 final in a [...] [Less]
|
|
Posted
over 13 years
ago
by
Frédéric Buclin
It’s usually easier to make Bugzilla work with Apache, but IIS7 made things a lot easier than in previous versions, and it’s now pretty trivial to make it work with IIS too. The screenshots below are in french, but I guess you can understand what needs to be done. Only two actions are needed, as [...]
|
|
Posted
over 13 years
ago
by
avatraxiom
Hey folks! I just wanted to let everybody know that there's now an official Twitter account for the Bugzilla Project. This will be a really good way to stay up to date on the very latest news about Bugzilla--we plan to keep it updated frequently about all our new feature development, releases, and things going on in the Bugzilla community.-Max
|
