Useful - Header, Jumpbar

RT Users
1

This is a useful thing that I’ve tossed in our RT system here, in the main
Header at the top. I call it a JumpBar, others will probably call it an
annoying javascripty thing ;).

It provides a dropdown box in the main Header (red bar, top of each page)
to start a new browser window to go elsewhere, amongst the URLs that you
provide. In our instance, we include a link to our internal web page[1],
ordering pages of our supplies, links to google, our monitoring system
etc.

The javascript code itself was copied from cnn.com, who in turn copied
from somewhere else… (etc). The attached example includes some fsck.com
links that you might find handy.

To use it, save the attached file as
/path/to/rt/WebRT/html/Elements/JumpBar. Then, put some lines in
/path/to/rt/WebRT/html/Elements/Header, like:

<td align="center">
<& /Elements/JumpBar &>
</td>

such thats its after the of the <%$Title>, but before the of
the % if($session{‘CurrentUser’}) { (etc)

Note that it won’t work with browsers that don’t do the javascript thing.
If I remember, I’ll knock up something to go in /NoAuth to do what is
described in http://www.lboro.ac.uk/computing/providers/redirect.html .

Have fun.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

[1] Believe it or not, it was started when some people[2] complained that
there was no link back to the main internal web page after they’d
viewed their ticket.
[2] For fecks sake. Your browser has bookmarks and a ‘home’ button.
Predictably, windows users :wink:

JumpBar (884 Bytes)

2

If I remember, I’ll knock up something to go in /NoAuth to do what is
described in http://www.lboro.ac.uk/computing/providers/redirect.html .

Actually, thinking more about this, I’m thinking that its a security risk
to link directly from an RT system offsite. Eg, if I follow a link from a
displayed ticket (http://rt.example.com/Ticket/Display.html?id=349856), to
a remote website, that website has just received, via my browser’s passing
of the HTTP_REFER field, the URL to my ticketing system, and the exact
ticket that I’m working on.

Ugh. Not a problem if the RT webserver is behind a firewall, but it is a
problem if its on a publically available webserver and you’ve got a
guessable password for people, or the authentication information for RT
has been passed on the URL.

I will knock something up for /NoAuth and do patches for the displaying of
tickets.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations
3

security via obscurity is not very secure. relying on it is poor.

seph

Bruce Campbell bruce_campbell@ripe.net writes:> On Mon, 28 Jan 2002, Bruce Campbell wrote:

If I remember, I’ll knock up something to go in /NoAuth to do what is
described in http://www.lboro.ac.uk/computing/providers/redirect.html .

Actually, thinking more about this, I’m thinking that its a security risk
to link directly from an RT system offsite. Eg, if I follow a link from a
displayed ticket (http://rt.example.com/Ticket/Display.html?id=349856), to
a remote website, that website has just received, via my browser’s passing
of the HTTP_REFER field, the URL to my ticketing system, and the exact
ticket that I’m working on.

Ugh. Not a problem if the RT webserver is behind a firewall, but it is a
problem if its on a publically available webserver and you’ve got a
guessable password for people, or the authentication information for RT
has been passed on the URL.

I will knock something up for /NoAuth and do patches for the displaying of
tickets.

–
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

4

Bruce Campbell bruce_campbell@ripe.net writes:

Actually, thinking more about this, I’m thinking that its a security risk
to link directly from an RT system offsite. Eg, if I follow a link from a

security via obscurity is not very secure. relying on it is poor.

Correct, if it was a case of security of the RT system itself. My point
is that releasing the RT ticket numbers to ad-hoc websites via the
HTTP_REFERER field is a Bad Thing ™.

As a real-life example, say that your neighbour mentions to his insurance
agent that you’ve been meaning to get insurance for ages. Which call
would you like from the insurance agent?:

'Hi there, your neighbour, insurance account 230984798, mentioned
 that you might be in need of our services.'

	(ala current RT with ticket # in HTTP_REFERER)

or

'Hi there, your neighbour mentioned that you might be in need of
 our services.'

	(ala an RT-site Redirection, no ticket # in HTTP_REFERER)

or

'Hi there, do you need insurance?'

	(ala, a new window for the URL, no HTTP_REFERER)

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations
5

Bruce Campbell bruce_campbell@ripe.net writes:

As a real-life example, say that your neighbour mentions to his insurance
agent that you’ve been meaning to get insurance for ages. Which call
would you like from the insurance agent?:

equating ticket ID to account info is sketchy at best. ticket IDs are
sent about in email, and generally treated as non-confidential
information. I really wouldn’t want that to change.

anyhow, knowledge of an account number, should not equate to
authorization. sometimes companies get this wrong. there’s no reason
rt should.

seph

6

Bruce Campbell bruce_campbell@ripe.net writes:

As a real-life example, say that your neighbour mentions to his insurance
agent that you’ve been meaning to get insurance for ages. Which call
would you like from the insurance agent?:

equating ticket ID to account info is sketchy at best. ticket IDs are
sent about in email, and generally treated as non-confidential
information. I really wouldn’t want that to change.

sigh. You really miss the point.

anyhow, knowledge of an account number, should not equate to
authorization. sometimes companies get this wrong. there’s no reason
rt should.

RT is merely the tracking system. Nothing more. The tracking system
should not hand out, to third parties, information relating to an issue
which could be used via other mechanisms outside the tracking system to
control the issue.

As I said in my previous mail, code to do this will be written, and my
employer at least will be using it. ( Actually, I’d additionally argue
that we’re required to do this as per 4.6 of RFC2050/BCP12 )

As for knowing the account number != authorisation, try the example below.

Farfetched? Its happened a number of times that I’m aware of. In all
cases, ‘authorisation’ was done simply by knowing the ticket number, and
convincing the issuer (Big Transit) that you were related to the problem.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Big Transit: Hello small ISP, you are ticket #123456789, whats the
	problem?

Small ISP: We have a DoS going on, and it seems to be originating
	from evildudes.com.  They've even been bragging about it
	at http://www.evildudes.com/attack/small-isp .

Big Transit: ok, we'll take a look

	( follows link via tracking system, evildudes now have
	  knowledge of #123456789 and surmise that it's related
	  to Small ISP.  EvilDudes, being Evil(tm), decide to get
	  Big Transit to disconnect Small ISP merely by using
	  knowledge of the ticket number. )

Big Transit: Hello there, whats your ticket number and name
	please?

EvilDudes: We've got case #123456789.  My boss has delegated this
	to me, and I'm Joe Bloggs.

Big Transit: Sure thing, I'll just update the ticket.  Ok, whats
	the current problem; that DoS still ongoing?

EvilDudes: Unfortunately so, and we've found that our router is
	developing a fault from the traffic.  We've got the router
	guys looking at it, but until they fix it, we're going to
	use our backup link.  Do you mind just blackholing our
	link with you so the EvilDudes will give up?

Big Transit: Oh my, sounds bad.  We can do that.  Say, I've
	noticed that our records indicate that your got Acme brand
	routers.  Do you want me to get our Acme contact to
	contact you?

EvilDudes: They'll be onsite in about an hour, so we don't need
	you to do that.  Thanks for your assistance.

Big Transit: My pleasure.  Give us a call when you've fixed the
	problem, and we'll re-enable the link.