Tag Info

Hot answers tagged

26

In a cross-site scripting attack, the malicious script is run on the client, but the actual flaw is in the application. That doesn't necessarily mean that it is a strictly server-side vulnerability, in that the flaw could be in the application's JavaScript, but generally, it is indeed in server-side code, and always in code that is delivered by the server. ...


7

It manifests itself on the client side, but that is because it is allowed to do so by the web application. The application doesn't validate the code that it sends back to the browser. And thats why it is a server side vulnerability. Think about it this way. What would you do to fix the issue of XSS? Fix the server side code or fix the browser?


6

Symlinks are like shortcuts, so if you create a symlink pointing to /etc/passwd, when you open the symlink your O.S. will open /etc/passwd. How the attack works? 1) Create a symlink in your computer to /etc/passwd e.g.: ln -s /etc/passwd ./symlink.jpg 2) Create a zip with the symlink e.g.: zip —symlinks -r photos.zip ./symlink.jpg 3) Upload the ...


6

I don't think it will open you up to SQL Injection. That said - while I am not an expert on Prestashop or it's code base, I got the impression that the sanitize function you linked to is not just used to prevent SQL Injection, but multiple kinds of vulnerabilities (notice the call to strip_tags on line 102). If this is true you should be careful that you ...


5

Remember that TCP/IP requires 2-way communication. Yes, someone can spoof an IP (with difficulty), but in doing so, they break the ability to receive replies. Spoofing an IP is usually better suited to "fire-an-forget" scenarios like DDoS.


5

You can't currently depend on the Origin header, because it is not implemented in all browsers which are in active use. Apart from that, Origin is not sent in all cases relevant to CSRF, like <img src=http://router/admin.cgi?...>


3

CAPTCHAs are one area of computer security where "roll-your-own" can be a good idea. In order to break a CAPTCHA, a bot needs to be programmed to recognize and solve the CAPTCHA. For low-volume, low-value sites, the cost to program a bot to handle even a trivial CAPTCHA such as this is greater than the expected value of breaking it. By the simple ...


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 ...


3

As per MySQL's documentation on the Encryption functions, http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html Caution Passwords or other sensitive values supplied as arguments to encryption functions are sent in plaintext to the MySQL server unless an SSL connection is used. Also, such values will appear in any MySQL logs to which ...


3

Encryption is not a good way to ban automated clients, because if a browser is able to decrypt the content of the contest, a good bod is able to to the same. But for the sake of completeness: A very easy way to eliminate automated scripts would be something only a human can solve. A very popular way of doing this is a Captcha. From Wikipedia: A ...


3

Cross-site Scripting (XSS) attacks can generally be categorized as one of: Stored XSS Attacks Reflected XSS Attacks DOM Based XSS Attacks The attack itself is taking place on the client. All three attack types could fully manifest themselves in the browser itself in the case of a single page or offline application. However, if the data is stored on the ...


2

This is a pretty scary thing to be doing, as by definition, you are wanting to look at sensitive, user-submitted data on those computers. Sure, you might catch the occasional wrongdoer, but you're going to be capturing quite a lot of normal people's passwords, emails, etc. Which is probably opening a whole slew of liability to whoever owns the computer lab. ...


2

Tools are always limited in my opinion. Testing an authorization mechanism and session fixation (I've yet to come a cross a tool that can do this) are just two examples a tool can't (properly) do. Tools are good for the so called low hanging fruits (most of the OWASP top 10 issues), but can't be called a penetration test. I generally use tools to get a ...


2

Manual testing: Slow; Humans can forget some important tests; Complex, sophisticated and creative testing. Automated testing: Fast; Tests a lot (thousands) of vulnerabilities (never forget a test); Easily repeatable after remediation; "Cake Recipe" (will just test what it was designed to test). Based on the above points, we can say that each type of ...


2

There are CSRF prevention techniques that do not rely upon a session-bound CSRF token, after all there is more than on way to skin a cat. When considering a CSRF protection system, look for any shortcut that doesn't exist with the commonly used CSRF synchronization token pattern. There are three concerns with this proposed CSRF protection system. ...


2

Depends on the context. A very short one: Context: <script src="%XSS%"></script> Let's say you are the owner/maintainer/administrator of http://.to (Tonga gTLD). <script src="//to"></script> XSS with 4 chars. Probably one of the shortest possible. There are dozens of other contexts. Edit: Tested on Chrome ...


2

The point of RFD is abusing the trust of certain sites and if I can make arbitrary files look like they are coming from a trusted site, I get to bypass certain warnings. (Is it my browser that already trusts certain sites or is it the user or both?) I think it is only meant as in the user will look at the downloaded file and think "Oh, it did come from ...


2

From what it sounds like this is not a problem limited to you. Many other WordPress websites have been hit. I'd expect someone to come out with a more comprehensive solution soon. That being said: ARS Technica just reported that it seems like a premium plugin called RevSlider is responsible for the security hole. Other than restoring the website from a ...


2

Ideally the application would be written to conform to a 3 tier architecture. In this scenario it is common for the Presentation Layer to reside in a WebDMZ, the Application Layer to reside in an AppDMZ and the Data Layer to reside on the internal network. If this isn't feasible for some reason or another, I recommend the database reside in a ...


2

For a reasonable level of security, the answer is really neither. The database should be housed in it's own zone, not the DMZ with the web server, or in the internal network zone. This allows additional levels of protection both against intrusion from the public Internet should the web server or web application be compromised, and against attacks from the ...


1

As others have already explained, it is very unlikley that an attacker will be able to perform active TCP spoofing of your IP address. What is more likely is that you make a common mistake in you protection. Many tutorials use the following example of how to configure restricted access: <Limit GET HEAD POST> DENY FROM ALL ALLOW FROM myip ...


1

You need to do a risk assessment for each site. and consider likelihood as well as consequences. It could be that some of your sites have a much higher likelihood than others. If this is the case, you could consider slightly modified approaches, such as keeping the high risk sites on their own system and only putting the lower risk ones on the shared system. ...


1

Anything sent in a request using the HTTP TRACE method will be echo-ed back in the response. This may lead to Cross Site Tracing (XST) attacks, which could lead to steal a user's cookie even if the cookie has the HTTPOnly attribute flag set. The HTTP TRACE method is used for debugging purposes only and should be disabled. Apache Configuration: ...


1

If a user can get your email server to spam emails, it could increase the likelihood that all emails from you are automatically marked as spam. In the worst case, you could end up on email blacklists and emails you send could be completely ignored. This is assuming you are running all parts of this on your own servers. If not, you might want to clarify.


1

I think the greatest threat could be Denial of service, you could send so many e-mails you could saturate your SMTP server, your mail server and your user´s personal inbox.


1

How effective are tools such as w3af in looking for web app vulnerabilities compared to looking for vulnerabilities manually? They are effective for what they are. Scanners will find the low hanging fruit. However, they typically fail at finding vulnerabilities caused by flawed business logic. In this area humans have the advantage. Scanners ...


1

The terminology is a little slippery, but usually an "XSS bug" is a client-side exploit of a server-side vulnerability. Cross-site scripting is not, in and of itself, a security problem. The problem is that it can happen without the end user's knowledge. Most sites aren't coded for this to happen, of course: either they don't use cross-site scripting at ...



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