<SARCASM>

That's right. If we tell everyone then too many people will start using the exploit so IBM would have to fix it and spoil the fun for the smart few who can put two and two together on their own.

</SARCASM>

The trouble with what you suggest is that companies have demonstrated over and over that they will not fix these problems unless forced by bad PR.

Peace,

Rob:-]

Useful discussion going on here. One thing I've always appreciated about the MythBusters show is that when they get into describing a process that someone could very easily turn into malicious use, they omit an important piece of the equation (and say they've done so).

I'd kind of like to see that with your posts on these topics. I don't think we need to be training script kiddies on these techniques. Point out the issue, explain why it's an issue, perhaps lead down the trail, but a complete working example of an exploit is not really a good idea.

My 2 cents.

As always though, love your stuff.

I don't see what you're getting at.

1) I don't get what you mean. The hacker is requesting a URL on their own server. Chances are it won't be Domino. It could be anything. They don't need the attacked server's router task to do anything

2) See 1. No need to use POST. The GET request will do.

3) Possibly. If applied.

1) Does the hacker need the web-query-open agent setup? - I presume this would fail silently if the router task isn't running on the webserver?

2) Can he/she use some javascript code to post the data silently to another webserver/website? (instead of using emails)

3) Would the field's html attribute, max-length, truncate the data put into a field?

And by having @Left( theField ; MaxLength ) in the field's input translation break the javascript code? (where theField's length is greater than MaxLength).

shouldn't this be enough to end the session on the server and make the DomAuthSessId invalid?

Link

A chap who thought he had been phished "knocked on the door" of a web site that was accepting donations for tsunami victims and found himself convicted of a breach of the Act.

If the IP address changes then log them out somehow. (The only way I can think of to log them out is to redirect them to the logout URL.) You could also log the hack attempt with the IP address and perhaps use it to ban that IP address somehow.

A simple rewrite of the session key generator to include the IP of the client in the mix should be enough. I'd think all keys are temporarily stored in a registry of some sort. When a cookie is checked, validate it against the IP of the remote host.

The only open backdoor is that people behind the same router (one ip on the internet) can hack each other, but that is a small problem compared to that the entire Internet can use your session.

I can't imagine it's very hard for Lotus to stop that. It seems odd that the same session is allowed to be accessed from multiple IP addresses. I can't imagine why it would ever need to. I can see the need to login from different PCs but surely the session id would be different for the two sessions in that case?

Jake

After communicating with Jake, we clearly confirmed that this works from another browser on a totally different IP address.

Sad.

Jake, since you've already set up the test code, if you want to ping me and work it out, let me know.

As far as I can see there are no Hacking Domino type threads around (well there are now you started 'em!).

But back to the case in hand.

There are two Domino problems here. Firstly is allowing user entered data to *execute* when viewing. I allow users to enter HTML. However when data is displayed it is done with the old < > tags. So what is sent to the browser looks just like the HTML entered. Not sure if you do it but if <script>alert('Boo!')</script> you got a spooky message then you are allowing stuff to execute.

Secondly is Domino's wierd pass-thru of using the square brackets. I'm sure we've all done it. Added passthru code directly on pages to allow RichText fields to pass the code dircetly. [<script>alert('Boo! (with square brackets)')</script>] My technique for stopping this is simply a WQS agent which does a search and replace and inserts a space between the two characters, thereby prevent the pass-thru from working.

There are a lot more possible attacks which are specifically Domino related. However as the saying goes "The law is an ass". There is a Bill going through Parliament at the moment which is an ammendment to the 1990 Computer Misuse Act.

It reads:

----

A person is guilty of an offence if he makes, adapts, supplies or offers to supply any article —

(a) intending it to be used to commit, or to assist in the commission of, an offence under section 1 or 3 [of the Computer Misuse Act]; or

(b) believing that it is likely to be so used.

----

Telling people about the hack would be considered a breach of the law. However by NOT telling people about the hack you would have commited another breach of civil law by allowing potentially compromised systems to remain in service.

So what it all boils down to is don't write or release any system which can be misused. Here we have a whole can of worms that can really upset things.

Lets hope the Police and Justice Bill gets re-written properly or thrown out. Otherwise we're all in deep do-do.

Dan

also intriguing is copy the following line of code into the address bar of any website, and be able to change the layout / text / images etc within it ....

javascript:document.body.contentEditable='true'; document.designMode='on'; void 0

enjoy !