Brief
I have been trying to write rules to protect a website from DoS attacks and the website have only one page /index.php. However, each user is identified by an unique token like this /index.php?a=abcdef. This page sends a lot of ajax calls that gets and posts information, periodically, as long as the user is active in the page.
Problem
During a DoS attack, I need to block only the specific user using the token ?a=abcdef, which is dynamic. And the actual length of the token is around 45 characters, consisting of [a-zA-Z0-9]. The website is visited by either a single user or user group (more than 10 users) from an IP address. The problem is, during a DoS attack, when blocking the user, I need to take the token into consideration. However, as far as I understand, unless I use a dynamic variable like, tx.dos_counter_%{ARGS_GET}=+1, I may not be able to identify an user uniquely. But when I reference the variable like this,%{tx.dos_counter_%{ARGS_GET}} to retrieve the value of the dynamic variable, it returns null.
Questions
Is it possible to use dynamic variables, as mentioned above, in ModSecurity?
Is there any other way to handle this problem?
Miscellaneous
This website runs on LAMP stack (Ubuntu) with ModSecurity.
Please help me solve this issue.
Many thanks in advance.
Thanks,
Daniel
Related
I need to use credential for log in to a system in AA for a bot that may run on different machines with a technical user for the system associated to each machine/bot.
Lets say the system is Stackoverflow.
Lets say I have two Virtual Machines,named:VM1, VM2
I name my credentials "Stackoverflow-VM1", "Stackoverflow-VM2" and want the automation to dynamically access those credentials, so that running on VM1 the automation will always use the VM1 credential.
I cannot find out how to use such a machine-dynamic access in AA while this is easy to do in other automation softwares and credential vault seems to be pretty useless without this functionality, especially with the extra concept of lockers...Any help?
Already tried:
1) The credential variables in AA will look like this from the client: $Stackoverflow-VM1(username)$, so i tried to simply write (not using the F2 variable list): $Stackoverflow-$Machine$(username)$ into the Set Text field but that results in the string "$Stackoverflow-VM1(username)$" written into the corresponding text field, which is consistent with the AA documentation:
https://docs.automationanywhere.com/bundle/enterprise-v11.3/page/topics/aae-client/bot-creator/using-variables/credential-variables.html
"Credential variables contained in the Credential Lockers can be seen and accessed only from the Insert Variables window."
2) I tried to create different lockers, where VM1 will only see "Stackoverflow-Locker-VM1" and a corresponding locker for VM2 exists. Now if i could create credentials with the same name but different content in each locker i could easily do this, but i cannot create identically named credentials, since they are aware of each other and not only defined in the context of a locker.
3) This page suggests its not possible: https://apeople.automationanywhere.com/s/question/0D56F00005dy3Ri/can-we-able-to-use-credential-vault-dynamically-?language=en_US
but its a 8 month old thread and possibly it has changed now. Everything suggested in this thread is not possible in terms of scalability.
Thankful for any input,
Thank you.
First thing I would suggest that you should always use F2 to fetch the variable list.
Returning to the question, to me, it seems that you have a system where you want to log in using different devices (bot runners) using different credentials.
It is possible by creating provided credentials values.
When you create an attribute for any credential, there is an option to mark the value as provided. That way, the associated users will get the credential request.
Each user will have to provide their own set of values. The bot can be created using those credentials. At run time, based on the user who is logged in, appropriate values will be fetched.
Disclaimer: I work for Automation Anywhere.
We have a site that uses a "one-time" login process for password resets which are not initiated by the user themselves. (for instance, a password reset that is initiated by an admin or another employee) A URL is sent to the user via email which can then be used to reset their password. The URL can only be visited one time. (there's more to this for security-sake but I'll keep it simple) Recently, some users have complained that when they visit the link, it has already expired. The end result is that they can't reset their passwords using this feature. We discovered that the users in question have a spam filter or "link checker" in their environment that they do not have access to. This device visits the one-time link before the user is able to, to make sure its safe.
I'm trying to solve this issue and was wondering if there's a way I can detect these type of devices on the web server when the request is made? When the spam filter visits the link, is there something in the http request that would stand apart from a regular browser? Maybe they all use a specific custom HTTP header? Or maybe there's a regex I could use on the user agent? I haven't been able to catch one of these yet, so I'm not sure what the request looks like coming from a spam filter.
Anyone know of a way to detect spam filters of any vendor by looking at the http requests? I know it's a long shot but maybe they all use a specific header for reasons such as this?
I got approval to modify the design to remove the one-time aspect of the URL. This solves the issue and saves me the headache. Thanks for the suggestion, #PeeHaa
I am new to REST APIs, I am actually not looking for any workarounds, I just need to clear my concept because I know I am missing some very important information which can easily solve my problem.
For E.g I made a small website, let's say using angular.js, where I will list some information or some items.
Consider it as an open website for now, everyone is getting same list. Anyone can come to the page and see the list of items. Simple.
Lets say the URL to this list is
https://www.example.com/api/list/v1
Result returned
1. abc
2. cde
3. efg
4. hij
Perfect!
Now my site got traffic, and I decided to implement user thing on my website, so that every user can only see his own information.
So I changed the rest api url to this:
https://www.example.com/api/list/v1/12345
where 12345 is userid.
The user with the user id came on the website, logged in, and browsed the list, by chance he went to the source of the page, and he found the url to list information.
He copied the url and started to use different user id's, he might get lucky any time.
I am not talking about implementing any type of security up til now, there must be several ways to secure it.
My main concern is that isn't it a large security hole, or we can call it an invitation, for injections?
So I just want to clear my understanding, where I am wrong?
Thanks
This is not some security loophole. This is the way it is supposed to work.
Let's put aside the case of APIs. Consider the simple example::
I have a url: www.example.com/jobs/
This will list all the jobs on my website. No authentication or permission of any sort is required to access this data. I am providing it to every user that visits my website. Now I need a way to figure out if the user visiting my website wants to filter the jobs available on my website. So I provide this option in url kwargs. This will look something like::
www.example.com/jobs/java/
So, now the list will contain the data only for Java jobs. Plain and simple.
Now some day I decide that I will let only the registered users to view Java Jobs. So, I introduce a new check in my View that lets you access the java jobs only if you are logged into my website. Otherwise it redirects you to the login page. Depending on the requirement, you put restrictions on the data being sent to the user.
Same is the case with APIs. If you allow the data to be available to any user that uses the API, there is a flaw with your design and not with the concept of APIs. APIs are just the implementation of your logic.
If you don't want a user with id 12345 to access the data of a user with id 123, you have got to restrict the permissions on the API code. You have got to handle themselves. The API will respond to your code.
Hope this clears out everything.
Are there some good resources tutorials or anyone has tried to implement a Capcha on devise when user enters x wrong passwords?
The idea is that the capcha shows up on to many requests to prevent bots or other bad guys out and limit the number of requests on the devise signing page.
I can think of doing that in two ways:
The first one is based on failed_attempts attribute (so you should increment it after each unsuccesful login). To use it on Devise, you may create your own FailureApp overriding the respond method to update to do an increment on the failed_attempt attribute on the user. When the user reaches the captcha limit, you may set a the flash attribute to signalize about this and thus, you decide on your controller about the captcha. But there is a problem with this way: as it logs for users, it won't work for an user trying different logins.
The second one is based on the IP: for each unsuccessful login, you keep record of IPs and unsuccessful attempts and when an IP reaches a limit you set the already mentioned flash attribute to signalize that the request number from that IP have already reached the limit and you can show the captcha. You can use ActiveRecord and a relational database or even something lightweight like Redis to do that. You may also think about ways to remove old data from this database.
Many sites with registration that ask email confirmation and sites use tokens in their url.
Why do they use it?
For example in case of email confirmation: why just not use registered user id instead of token?! In case of using it in web pages, i didn't get at all!!
Explanation with real applications would be appreciated!
Thanks in advance!
A token in this context is typically a disposable time-limited random string used for verification. A token of (say) 40 characters can be generated easily [such as sha1(microtime() . rand(1, 10000)))], which isn't guessable by the user and isn't brute-forceable (within reason).
For email verification, a token will be generated and linked with your account ID. When you visit the address containing the token, the account gets activated. Since we've established that a token can't be brute-forced or guessed (within reason), we've just established that a certain user does indeed have the email address they gave us.
If we just used their member number, they could do several things to just guess it, thus bypassing the email check entirely.
When logging in or submitting a form of some kind, the term "token" may be used in a slightly different context - it's still a disposable time-limited random string, but it's used to make sure that the person who submitted the form has just come from the form they tried to submit.
For example, say you log into your online banking. They might have a form to transfer money to another bank account. If you go to www.nastysite.com they might include an iframe that points to <iframe src="http://www.mybank.com/send_money.php?amount=9001&to=Joe">. If your bank don't verify that you were actually on the form, that payment will go through, and you won't be best happy. Even if you are on the form, the chances of the correct token on your form being used in the fake page-load are (almost) nil.
This is called "Cross-Site Request Forgery", or CSRF. For some more reading on CSRF, have a look at this Wikipedia article. Also, I've just got that link after writing this post and seen that they use a very similar example to mine - genuine coincidence haha.