New answers tagged web-application
2
You can't do it using the MAC address - these are not visible across routers. Even if you were on the same LAN, it doesn't solve the problem (as posted) since it's trivial to change a MAC address.
The big question is how closely you need to stick to your requirement.
There are lots of solutions such as simply authenticating the user, using authentication ...
2
You can use Kerberos network authentication protocol for authenticating user before accessing the machine. Kerberos provides strong authentication for client/server applications by using secret-key cryptography where both client and server prove their identity across an insecure network connection. I recommend to read "Best Practices for Integrating Kerberos ...
1
As far as automated SQL injection testing goes, my goto tool will be sqlmap.
The Burp Suite like you mentioned also has a very good set of tools for this kind of work.
0
How secure do you need to go?
This is probably as "secure" as you can make it. It's not technically safe. As Rook said, there are still things here than can be exploited. These are a few steps you can take to try and harden the system:
Setup the web server on a physical server on the office LAN. Do NOT use NAT to connect any outside traffic to the ...
1
The problem with this implantation is that the CSRF token is not actually stored within an anonymous function. This token would be stored within text that declares an anonymous function. An XSS payload can request this text from the server using an XHR, the CSRF token can be read and another XHR can be used to send an arbitrary forged request.
Related: ...
2
There's a couple of things you can do to help restrict the use of the application to a specific office location and specific devices, although as other answers point out none of them are absolute protection
Setup a firewall in front of the application to restrict the IP addresses allowed to access the application to the clients external IP address range. ...
2
The only time that you need to worry about the token being read is if there's a malicious extension or an MITM attack being carried out.
In both cases, it's no longer a CSRF problem. Both attacks have the capability of catching the request on the fly (after your javascript has assembled it with the token) and modifying it. This isn't CSRF, but it's still a ...
0
What you're trying to achieve is not possible. HTTP isn't designed to provide hardware-specific identifiers, the only "identifier" is the User-Agent which isn't identifying at all, and it can be spoofed, so the browsers don't even access that information.
Even with a client certificate, it just can be exported from the browser to another device.
Tell your ...
1
You just have to host the web app on a server on the intranet that is not connected to the internet.
Proper routing and firewall measure should ensure that no one that is not connected to the local network has access to the web app.
If people outside the network needs access to the web app, have them setup a VPN connection to your local network.
4
There are various levels of protection you can use. The most basic would be to configure them as separate sites running as different users and only allow each site's user access to the assets it needs. At a basic level, this should prevent one site from being able to access the other.
There are still some attacks that may be able to escape this though (if ...
6
If you have multiple websites on the same server then depending on the issue, a security problem with one site may well affect another.
Mitigating this essentially means increasing the separation between the two applications. You could do this by using somthing like a chroot jail or if that's not enough isolation you could look at using VM guests on the ...
0
Well, first you have to define the word 'theft' in this case.
All the content I've seen so far on YouTube is for free anyway. The only protection there
I know of is preventing users from recording video streams for off-line viewing or viewing not via your flash-enabled browser or manipulating the stream.
Against this they use RTMPE/RTMPS streaming ...
6
The relevant practice you're describing is leeching and the immediate connotation is inappropriately as harsh as the term "junk bond".
Your conceptual description is accurate but YouTube's content is leechable, sites like HuLu, even CSpan go to greater lengths to protect their content by instructing your browser to cache the content in your systems RAM ...
4
Recommendations to management need to be framed in terms of effort, costs, and risks. 'Best Practices' and marketing-speak will not communicate well on their own, so defining the problem in terms of effort, costs, and risks will keep everyone focused on the realities of the situation.
Your 'outsider' is not helping the discussion with tossing around a ...
4
This is most likely a PHP LFI (Local File Inclusion) attack. The .php.jpg "photo" actually contains valid PHP code that is then parsed by some other script on your site which is vulnerable to LFI.
The other files you found were dropped post-exploitation after the LFI vulnerability was exploited.
You can post the boy.php.jpg for further analysis. Host it ...
-1
You should definitely inform all the stakeholders of your website who might be in danger if any sensitive data was leaked. Also, you should compare your current code with the original code and do a code reversion to make sure any malfunctions that were inserted are removed. Check your VPN and communicate with the authorized people in your company to be on ...
12
If the only user on the database that can change records is root and your CMS uses the root user to perform queries then you have a problem. Your root user should never be used by a website.
Get a limited user which can only access the tables and records he needs to access restricted with the right permissions. If he doesn't need delete or update, then ...
12
Get a known clean version of your site and identify the differences between the known good code the and current (hacked) production code. Study how the changes may have been made and repair.
Update the passwords.
Fix the FTP certificate issue - consider using 2 factor authentication.
Find a way to scan your code for vulnerabilities - peer review or ...
0
Of course this is a baseless fear.
Javascript is only one part of a larger ecosystem, much more important is brand, site usability, site integrity, responsiveness and network effects.
Yeah, javascript minimisation, optimisation is good to do, but not because of these purposes.
If a competitor steals you code, you can go legal on their tails, and kill ...
1
Using window.confirm() is a valid method of mitigating Clickjacking when it is not possible to use x-frame-options. This popup window cannot be framed. In every browser except for Internet Explorer the origin of the confirmation window is displayed if the domain differs from the parent iframe in the popup because of Clickjacking. The use of ...
6
I think the operative word in the question is "afraid." The aversion is based on fear, not fact. The reality is, the threat model isn't particularly realistic. Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's JS ...
3
You seem to already know that obfuscation isn't actual protection, so I'm not gonna lecture you on security by obscurity.
What makes sense is this: Put your competitive code on the server to protect it, then obfuscate client-side code as much as you want. Granted, it won't give you much security but it'll definitely deter kiddies snooping around, and it'll ...
2
No. Obfuscating Javascript usually makes no sense whatsoever. Always assume that any logic you place on the client side can easily be obtained by a determined enough attack no matter how you obfuscate it.
Your "important" logic should be stored server side.
1
Is it feasible? Yes. It's a standard pattern for cookie-less session and was a de rigueur pattern for session management in JSP app for a number of years.
Is is a good idea? No, for a couple of reasons.
One of the primary vulnerabilities for a site that has a concept of session management is session hijacking, where the session id is sniffed and ...
3
It's a bad idea.
Encrypting the session identifier has no real impact on the security of your application. If the traffic is sent in plaintext (without SSL) anyone is able to read that encrypted session ID and then use it to impersonate the legitimate user.
Let's say my session ID is 12345. Every time I want to go to your house you ask me about my session ...
3
If your session ID is truly random, there is no additional security in AES-encrypting it. If, however, it is not random, I would strongly recommend against doing so, for reasons similar to why no-one sane uses predictable session ID tokens.
Also, if you're not using SSL, your traffic can be sniffed. This means that, no matter how much you encrypt the ...
1
You need to be aware of (at least) the following:
If your documents are in a publicly-accessible folder, they're not private. This includes simple protections such as checking the referer, which are trivial to juke
If your documents are in a folder above the HTTP root, it is one step better; if they're encrypted and only one script can read them, even ...
-1
Along with the good reasons that bobince mentioned, there is also that you cannot create a properly trusted SSL/TLS certificate for a site that doesn't use a DNS domain name. Thus making all browsers trying to connect to your HTTPS:// version of your IP addressed site complain that they cannot trust it.
3
Contrary to the other answers, I consider that using ip-addresses instead of hostnames is bad practice for a number of reasons. Most notably:
It is considerable harder for average users to verify that they are talking with the correct service and not with a phishing site: They have to remember a large number instead of a name.
Using ip-adresses implies ...
12
Typically if your site is accessible as http://1.2.3.4/ that would imply that it is not enforcing any limitations on the Host: header. That would mean that you could access it not just through IP address, but any hostname that happened to resolve to that address - including a domain an attacker registered and pointed at it.
This opens up DNS rebinding ...
1
Using the IP address instead of the domain is not a security bad practice, as an attacker could get it trivially.
A simple terminal command like nslookup can check for any IP address resolved by the given domain. Furthermore, if the domain is connected to a single IP address, ping does the job just as well.
Giving your [web site's] address one way or the ...
29
Easier to hack? No. Easier to DoS? Potentially. Using an IP address instead of a host name with a DNS entry means you're giving up a layer of routing flexibility that can be very beneficial.
For example, if malware targets your IP address in a DoS attack, if you're using a domain name, you switch the IP address of the site and in the DNS record, and ...
1
It can't be a security concern because everyone can find out the domain IP address.
for example check this out: ip-lookup
1
What precaustions should be taken when the file displayed by a webpage is specified by the GET value
To answer you question, it all depends on how your site treats the input parameter. If, like mentioned, it is possible to change the directory using the input, then yes.
GET params just end up as strings when it gets to the php; You are not sending it special commands like you would in a command line interface (unless it is coded that way in the php).
4
What precaustions should be taken when the file displayed by a webpage is specified by the GET value
You should be sure to put additional filtering on it to make sure it doesn't try things like that. Personally, at a minimum, I would attempt to parse and reform the input and make sure that no operations like directory changes can occur.
A better option would be to store the filenames in a DB and pass in a simple token that could be used to look up the ...
2
You can segment your tables into sensitive and general. Sensitive tables should not be "Exposed" but "Aliased". In the long run however, your solution is only as secure as the value it holds for the person interested in getting in.
7
More information you expose more vulnerable you are, no matter of his priority in your security policies.
11
Exposing table names might have broader consequences than you expect. For instance you could be putting your company at legal disadvantage by disclosing a table names like "deleted_messages", "profile_views", "single_female_users" etc. Retention of that data and user privacy suddenly becomes a topic of discussion and can cost much.
You cannot always control ...
42
Think about it this way
On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. ...
2
As a pentester being able to find the subdomains for a site comes up often. So I wrote a tool, SubBrute that does this quite well if I do say so my self. In short, this is better than other tools (fierce2) in that its a lot faster, more accurate and easier to work with. This tool comes with a list of real subdomains obtained from spidering the web. ...
0
This is an official information about MD5 - MD5 vulnerable to collision attacks
For higher security SHA-2 should be considered. No one stops users from using MD5, but not for the data you want to keep private.
Performance of hash algorithms
As shown in the diagram "Performance of hash algorithms", SHA256 is way faster then MD5.
This is a good resource to ...
4
Most of the OWASP top 10 still applies to web services. A more detailed resource would be the Mozilla WebAppSec Guide.
"RESTful" web services should not have a "session token". Related: "Do sessions really violate RESTfulness?" However at the end of the day you need a some kind of token for authentication purposes.
In short, if you are writing a ...
0
Dominator pro is excellent when it come to xss. I had used it and found xss on multiple site like apple,yahoo,google,wizehive and in payment gateway of accessnow.org and flipkart etc. The bad thing about tool is, it is freezing time which is most important.
0
Generally speaking ,,
Do not trust Any Thing (headers, hidden form, validation, etc..) that depend on the browser(client side)
use burpsuite , WebScarab or any other proxy to intercept your request, you'll see how dangerous is it.
You can imagine that if your authorization depends on "referer" and user change the refere to the valid one during browsing, ...
1
This is often known as a service or API key. You are trying to setup a web service. Generally, the client site will submit a request for some action to be done with a publicly shareable identifier that lets your system identify who sent the traffic your way. It should likely be paired with a private code that is used for your server to respond back to ...
2
There's a little detail here on how Paypal issue Application IDs for issuing on servers which will host applications making API calls to PayPal on behalf of merchants/service providers - https://www.x.com/developers/paypal/documentation-tools/going-live-with-your-application#register
The approach you're taking above is similar so it's a way of providing ...
1
There aren't certificates I know of to validate a web application but rather certs for processes e.g. you could have your development cycle certified to ISO 27001. You could also follow OWASP to ensure your doing the appropriate vulnerability testing and adhering to a secure development lifecycle.
As you're providing a SaaS, you could go through the Cloud ...
2
The most valuable certificate is an SSL certificate. Jokes aside, this is a question that merits the universal answer...It depends. Specifically in this case, it depends on who your target audience is. Many large companies want to see ISO 27001 certification. If you're targeting E-commerce, they're going to want to see PCI certification. Healthcare in ...
1
There aren't really any "certifications" for web-apps. The closest I can think of is PCI-DSS, but the web app side of it is minimal - it's largely applicable across infrastructure and business processes, and heavily focuses on card payments.
If you're specifically looking for certifications, then web app development certs might be a good choice for a ...
3
Yes there's a risk as this is a classic session fixation issue (OWASP Page). Standard good practice for web application session management would always be to re-issue a random session token whenever the user submits a login. Anything else (either not re-issuing on login or allowing user set session token values) is not a good idea.
How much of an issue ...
Top 50 recent answers are included
