Tag Info

Hot answers tagged

32

These types of spurious requests are very, very common. They are either looking to see if you are already compromised, or looking to get your server to throw an error to gather info about your server (from error messages). You aren't the only one: http://shadow.wolvesincalifornia.org/awstats/data/awstats092014.shadow.wolvesincalifornia.org.txt # URL with ...


12

The attacker tries to find out if you have certain premade web software installed by requesting files which are typical for them. When they find out you use, say, wordpress or phpbb or mediawiki, they can then try to use exploits specific to these applications to take over your site. The best countermeasure against this is to avoid installing too much ...


10

Yes, those are scans. If you Google those strings you will see that they show up in the web logs of numerous sites throughout the Internet, usually cheap webhost sites which put their logs up where Google can see them. This is sufficient indication that some tool is trolling for that URL. There is not enough information to indicate what the scan is ...


4

That is the correct behavior. In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed. So, the fact that you can manually browse to the URL for the script file is irrelevant. It gives you no more access than the application intends for you to have. A source-code disclosure vulnerability is when ...


4

Is your system publicly accessible? Yes: Someone is probably scanning it. No: Are you scanning the server? Yes: Well, you've just answered your own question now haven't you? No: It's probably not getting scanned. I don't know: Wait... what? I don't know: You've got bigger problems. And yes, you're probably getting scanned.


4

Since all the requests fail with the "404 Not Found" status, try to create a custom 404 error page that will log everything (all headers, the request, the user's session) and debug this, see if the actual requests come from just a few users with a busted web browser (virus, trojan etc. on the client machine), from all the users, just from users that are ...


4

Burp has some relatively complex options available for session handling but in the basic case, the scanner will use sessions from burps "cookie jar", so as long as it knows about a valid session ID it'll use it. If you invalidate your sessions while the scanner is running (for example by using logout functionality) then the scanner will likely stop working ...


4

These requests are caused by Adware:Win32/Adpeak malfunctioning (yeah, believe it or not, even malware can malfunction). It sets up a proxy server on the infected systems that injects script tags in all HTML content that passes through it, similar to <script type="text/javascript" id="2f2a695a6afce2c2d833c706cd677a8e" ...


3

Most commercial and free web app scanner are active scanners. Both W3AF and Vega generates traffic. So they are active. Damage due to testing for SQL Injection may depend on both App and Scanner. If your app has DROP and UPDATE queries, in case of Injection, you may lost the data even SELECT query is sent by scanner. In some SQL Exploitation tools like ...


3

Web app vulnerability scanners typically use a combination of active and passive vulnerability detection, with the majority of the testing done actively. For example, if the scanner requests a page and it returns a cookie without the 'secure' flag that is essentially a passive test. But if the scanner is trying to find an XSS vulnerability in a parameter ...


3

It is best to plan out and control each URI (params or not) sent to the active/passive scanning engine. The target analyzer in the engagement tools (typically selected from the Target sitemap tab as "Analyze target") is a great place to select parameters and then "send to Intruder". Typically, you can customize your fault injection strategies in Intruder by ...


2

A source code disclosure vulnerability is an involuntary disclosure of source code. Since JavaScript code runs client-side, on the browser, it's disclosure is intentional. Under this definition, only exposure of the server-side code is a source code disclosure vulnerability. The example you give actually has the GPL on it, so it's already disclosed ...


2

Yes, all your assumptions are correct there. As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable. For example, addthis.com may suddenly decide they want ...


2

When scanning over a network, the topology between the scanning software and the server you are scanning is very important. Some tools need to be run on the server you are scanning. Depending on the type of scan you are doing, some tools will require that you run them on the server you are analyzing. This is usually done in what is called white-box ...


1

Configure your browser to point to Burp's proxy details (e.g. 127.0.0.1:8080) and then configure Burp to use an upstream HTTP proxy for all target hosts (* as the destination): However, if the upstream proxy is SOCKS, not HTTP, you need to configure it underneath (under the SOCKS Proxy heading) instead. This causes everything to be fed through the proxy. ...


1

You can detect the use of known bad dependencies with OWASP Dependency-Check I found this also looking for tools which attempt to exploit the known issues repetitively. It's looking like I may have to modify existing active vulnerability scanners.


1

If you are running a web sever, you might also want to set up a honeypot in your web application and trap automated scans. This can be done by configuring a section of your site, and disallow it in robots.txt. Any automated scans will ignore this, and will actually try to scan it. Any IPs accessing the disallowed area can be blacklisted using fail2ban for ...


1

Some applications have aggressive session expiration logic, such as destroying a session if a single bad request is submitted. Others are more forgiving. In any case, you can use Burp's Macros to continuously validate a logged in session and to re-login if a Burp request triggers a logout/session expired action. Yes, you want to ensure you have a valid ...


1

Extending the OWASP theme... OWASP highlights a top 10 of issues to be concerned with: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project As well as the top 10 it is worth reflecting on the attack surface you are managing: https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet One of the OWASP tools, Zap (Zed), helps spider your ...


1

Check out DirBuster where you can feed wordlists and it'll try to brute force file and directory names. Nikto also checks for commonly used folder and file names on a web server. It is not possible to check every file and folder name, however running the above tools will give you a decent amount of enumeration.


1

Chances are, if you are having a problem with this, you may have a shell installed on your sever. Shells are php backdoors that are normally installed by an attacker through some sort of remote file inclusion vulnerability. First thing to do, is to breath and don't panic. Find the snippet of injected code in the js file and remove it. Chances are, it has ...


1

The biggest challenge in developing secure (web) applications is implementing a secure (or security) development lifecycle process that is both effective and measurable. Enumerating all of the facets of such an undertaking is not possible here; but suffice it to say there are hundreds of books and white papers written to address the subject.


1

Short version : there is no central / unique command to check this by default on linux .. but you could rely on several tools, depending on the kind of scanning that you would like to find : Fail2ban to parse log file (ssh server, web server, ftp, vpn, etc.) in order to find any brute force / irregular login attempt (and trigger some firewall rules) On ...


1

If you are trying to catalog all possible attack inputs, creating a list of all form input fields would be incomplete and could lead you to having a false sense of security. There are many other potential origins of attack (parameters in the URL is a very common one). One thing that helped me when I began looking at website security was to start viewing it ...



Only top voted, non community-wiki answers of a minimum length are eligible