How to Identify URL calling page

[Terry26564135miig]

We have been having Cyber attacks and I have handles most with error trapping. I would like to improve on this by trapping any page calls that are not from our domain. Is there a way in ColdFusion to identify the calling url? 

[JJ Frankowski]

This doesn't exactly check the URL that is calling it, but you can check if the call is coming from your server by comparing cgi.local_addr and cgi.remote_addr and if not, do logging/redirecting/etc. 

[Terry26564135miig]

This was a great Idea. Unfortunately it didn't work on my scenario. I'm not sure if there is an easy solution, but to explain the issue a little better.

You can call the "index" page which can call "page2".

You cannot call "page2" directly. In addition, if you call "index", you still cannot call "page2" directly. 

Page2 can ONLY be called from a post from another valid page in the website.

Calling Page2 improperly either must be blocked or logged. Logging would be best since it would show the improper usage.

[Charlie Arehart]

Look for an empty value of cgi.http_referrer. While it can be spoofed, of course, most automated tools banging away at your site won't bother.

But a real person who goes to page2 from page1 will show the referrer being page1 on page2. 

[Terry26564135miig]

Thanks, I'll try that.

[Charlie Arehart]

Terry, any news on attempting either what I or James had proposed? 

[James Moberg · Accepted solution]

Have you reviewed using the csrfgeneratetoken() & csrfverifytoken() functions?
https://cfdocs.org/csrfgeneratetoken

[Charlie Arehart]

Good one, James. I'll add that I use that successfully on forms where I don't want people automating calls into the form action page. But sure, one could conceivably put such a check on all pages using application.cfc/.cfm for what Terry seeks. BTW, Terry, if you didn't mean for all that contact info to be there, you can edit your reply (or I can if you somehow cannot, being new here). 

[Terry26564135miig]

I don't see any way to edit my past messages. How do I get to my messages
to edit them?


--

[Charlie Arehart]

Terry, while I don't know the process or time line for how Adobe decides to allow one to edit their own posts, I did specifically offer to make that edit for you, in the note you're replying to, as I've heard of that challenge from other new users. I've gone ahead and removed all that contact from your previous reply, assuming that's what you sought to do. If anything else, let us know. 

[Terry26564135miig]

Thanks.

[John123]

We deal with this by setting a request value in each Index page and other CFM's check for this value and if it does not match the request value is redirected to an erro page. To apply to an existing app its a little cumbersome as yo uneed to edit every CFM to include a check. We call a function at the start of every page that does this check and other checks like a valid session.

[Charlie Arehart]

John, when you say "a request value", can you clarify? Some might think you mean cf's built-in "request " scope, but you can't mean that as it does not persist from one request to another. Perhaps you mean a session variable, or something else.

(And had you considered the verifytoken feature that James referred to above?)

Finally, as for your needing "to edit every CFM to include a check [and] call a function at the start of every page", it would seem you could instead leverage application.cfm/cfc as I referred to earlier here. Even if you might say, "well, I didn't really mean every page", note that there are ways one could implement code to indicate what pages should not implement such a feature, within such code at the app level.

As always, just trying to help (you and/or other readers), not criticizing. 

[John123]

I do mean cf's built in Request scope. To stop users entering the application at location other than the desired CFM's we set the value request.valid = false in the request start logic. On valid entry points, e.g. index.cfm pages, we set request.valid = true. On all pages that are not valid entry points we check the value of request.valid and if it is not TRUE then we redirect to a message page. Yes this could be done in request start in the application.cfc with some logic to determine the page but this is a very old application and this is the logic it had been coded with and it works.

This only prevents users entering the application from other than desired entry points it does not really address the original posters requirements of trapping attackers from outside your domain.

I appreciate your questions/comments, not taken as a criticism.